How does this address the issue that if B is a static class (regardless of its level of
complexity), you can't test class A without also testing class B (because you can't get A
to work against a "mock" of B without changing the source code of class A)?
The complexity of class B is only an issue if you decide that it's unimportant
that tests of class A are actually also tests of class B -- only if B is
completely trivial is it ok to disregard the dependency on B.
Class A's source code must "spell the name" of class B explicitly when class B is a
static class. But class A could instead operate on an instance of any object that implements the
needed interface (perhaps getting that instance passed to its constructor). Thus, it is much
easier to "mock" the functionality of class B if you use singleton rather than static
classes. (Again, the complexity of class B is not relevant.)
OK, so it wasn't as good a definition of what I do as I thought.
I have static utility classes that use strings, objects (reflection), XmlNodes
and a couple of other basic Framework classes. In testing these, I have
no interest in separating the testing of my class from the Framework class
it works with.
Pretty much everything else is either sufficiently complex to warrant an
instance of its own, or implemented as a singleton mainly for the benefit of
unit testing.
There is still a break-point at which a singleton just isn't worth it.
I guess I'll
just have to work on the definition of when that is.
John
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
