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!