Unit Testing, Agile Development, Leadership & .NET - By Roy Osherove
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
Where should we start? Well, I'd start by bringing your post to the attention of Brad Abrams and Krzystof Cwalina, since they seem to be the most influential guys in the Microsoft community in terms of API design. If you can get them engaging with your ideas, you're halfway there.
Personally, I like my polymorphism with hummus.
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.)
I wouldn't want to change my design just for the sake of testability (see http://www.elilopian.com/2007/02/26/object-oriented-testable-designed-you-must-be-out-of-your-mind/)
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).
Thanks for this! How quickly we get that debate again! (plug warning) I am doing a workshop on testability and encapsulation and this inspires me. I almost thought that everyone already had gone past the encapsulation debate and that I wouldn't get anyone to discuss with - but here it is again!
workshop: http://www.spaconference.org/spa2007/sessions/session67.html
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!
Pingback from Eli Lopian’s Blog (TypeMock) » Blog Archive » Object Oriented Testable Designed - You must be out of your mind
Phill Haack just released HTTPSimulator - a class to help with running tests against a simulated Http
Pingback from HTTPSimulator - Simulating HTTP Requests for unit testing made easier « Tuff Stuff