Friday, July 22, 2011
Unit testing is hard....
The main reason that unit testing is hard it that it requires many of the things that good design requires.
Built in dependencies
It’s much easier to hard code things, strings, external dependencies, statics and so on. It’s more effort to coordinate gathering up the various external requirements for a class in a sensible place, and then pass the external requirements on to that class.
In c# for example it is easy to have a class directly call:
featureEnabledString = ConfigurationManager.AppSettings["EnableFeatureX"];
Of course, now in order to run unit tests, you need an App.config.
And if you want to write a test where that feature is disabled, you need to get creative.
Perhaps you set up a derived test class to set the value of base.featureEnabledString so that you can test the thing that needs testing.
That’s all well and good for adding tests to existing code, but now, you are testing your derived test class, as well as your production class. And they are more or less the same but not exactly the same. (That’s a pretty good definition of a bug, it’s more or less the same as I what I want, but not exactly.)
As you class starts to do more and more things, it gets harder and harder to manage the testing.
As the complexity of your class goes up, and internally a, b and c all interact together, it gets harder and harder to manage testing.
But the underlying problem here is not testing the class. The fact that the class is becoming harder and harder to test is a really good indication that the class is too big and too complex.
If you can’t test it, it’s probably too complex to work in the real world too.
If you need to set up 20 different things to get a test to work, it’s probably too complex to work in the real world too.
Don’t shoot the Messenger
The unit testing is not the problem. It’s just bringing the bad news. Your code needs some reworking, refactoring, rethinking.
Zapping the unit tests, checking it all in leaving the mess for someone else is more befitting of an elected representative than a Software Engineer.