I'm a firm believer that unit testing should be a
platform service, not an add-on via libraries. If the
platform supported a unit test mode, we wouldn't have
the conundrums that we do.
Imagine, if you will, a 'unit test' switch on the CLR
such that:
- only unit tests can be executed
- unit tests have unrestricted access to their unit
under test.
- unit tests have unrestricted ability to mock types
that they wish to.
- perhaps, even, mocks could be created automatically
based on some unit test attributes.
What I'm getting at is that until unit testing is a
platform service we are going to have hacks around
accessibility, mockability and all round testability.
Love to hear your thoughts Roy,
Kent
I think OOP and Tests go well together because OOP is
about hiding implementation details and so are tests. If
tests are to allow constant, painless, refactoring they
must not interfere with the internal representation of
classes in the system but rather test their behavior
using the same public interface the rest of the system
uses. If you find a need to test internal aspects of a
class then that class should probably be split into two
or more classes which can be tested seperatly and
combined at runtime to produce the desired behavior.
Yoni, I'm not sure I can agree that tests are about
hiding implementation details. I'm relatively new to
unit testing, but my understanding is that a unit test
should verify the function of a single member, which may
often include affecting non-public
fields/properties/etc. Even in the scenario where you
split "larger" classes so that each can be black-box
tested, you still need to expose those classes
publically so that a testing framework can manipulate
them.
And on falafel, I spent two weeks in Israel in the 90's
and ate falafel from a street vendor almost every day.
Since coming home, I have yet to find the same quality
falafel anywhere, (in Ohio at least.)
John, I think it depends on what constitutes a unit in
your design. For me the smallest cohesive unit is
usually a class, a single member isn't worth testing out
of context because it isn't a complete behavior (and if
it is it's probably the only public member of the class
to begin with).
I think some of the things you list as "OOD" are not
object oriented design principles at all and, in fact,
violate object oriented design principles.
* Singletons are global variables accessed through a
global name. Strict OO design would only allow objects
to access other objects that are referenced through
instance variables or method parameters.
* Only make methods virtual explicitly? Polymorphism is
fundamental to OO design. Without polymorphic methods
you can't do OO design!