Testable code – is it worth it?
Recently I been refactoring some legasy code and writing a new one. I am using Rhino mocks to run my units and for that I have to write my code in a testable way. This approach makes my code looks not exactly the way I designed and want it to be. Eli Lopian wrote an article about this issue – "Stop Designing for Testability" and has some points to think of.
In my opinion, if we have to write very simple code to encapsulate some internal logic for our base class and make sure that there is no way some smart ass will override it, but still give an opportunity to reuse this code in the deriving class, like this:
public abstract class MyBase
{
protected void DoSomeVeryImportentLogicThatCanotBeOverriden()
{
DoTheSameVeryImportentLogic();
}
internal virtual void DoTheSameVeryImportentLogic()
{
// logic goes there.
}
}
Only to make the code testeble – we are missing something – this is not the way code should look like.
There is also the impact on performance of making all our methods as virtual, to be able to override them when we make out mock classes, I agree with Roy Osherove one this on and we are not dealing here with real-time applications so the impact of the vtable that created when we are performing polymorphism (you can read about it from Shimon's post) is not so painful. And as Roy explained in his post if this is your pain in the ass you can deal with it.
I don’t really like the idea of losing the concept of OOP and clear and simple code writing over testable code.
What do you think?