Roy has posted a new design methodology: Object Oriented Programming that is Testable!
Roy and I are on the opposite sides of this methodology. I personally hate to change my production code just for the tests.
As Roy says “pure object oriented design does not go well hand in hand with the notion of testable design.” After creating a good design (without taking testability into account), there is no real business value of implementing hooks to change internal private members and to expose properties that should remain private by design! Unless you want to clutter your code with load of Totally Irrelevant Code
Please, Stop Designing for testability!!
There is no need to do this, using the right tools you can enjoy both worlds.
We all have have seen testable code. The code is hard to maintain and understand. A Testable code, will have many interfaces that have no real design value, that will just confuse developers. Have you ever tried to browse a code with loads of interfaces, it take ages because you have to keep finding the concrete implementation, and the place where the instance was created.
Think about this code smell: When you find that an interface and implementation have exactly the same public methods, it is a sign that the interface is not exposing a trait of the object but the Object itself. This is what happens when your code is Designed for Testability, you do have a safety net, but the design is flawed.
Using TypeMock.NET your code can be encapsulated (OOD) and Testable at the same time:
- OOD: Do not expose any private members or methods that are not needed by the developer using your API .
- Testable with TypeMock: Easy to replace private instances of objects without changing your code or exposing unnecessary parts
- OOD: Seal classes to inheritance by default unless you explicitly mean for others to extend them
- Testable with TypeMock: No need to extend and override your objects just to test them
- OOD: Only make methods virtual explicitly when you want others to override them.
- Testable with TypeMock: Keep your methods non virtual (its faster). you can still test the code.
- OOD: Use singletons to make sure only one instance exists. do not allow anyone to touch that private instance.
- Testable with TypeMock: Don’t allow others to replace Singleton instances, TypeMock will do it for you in your tests.
- OOD: make types private or internal by default unless you want to expose them specifically.
- Testable with TypeMock: Keep your types private so that you can hide the implementation, you can sill test the code
- OOD: Don’t add unnecessary API’s
- Testable with TypeMock: No need to clutter you production code with special API’s