Unit testing may be a proven way to get defects out, but I don’t think it’s the best strategy. Here’s my short list of reasons why I’d choose code reviews over unit testing.
- Change the code, break the unit tests. Now you’ve got two things to maintain.
- Hard to mock up complex objects. What do you do when the unit you are testing depends on a complicated interrelationship of many objects? You’ve got to create the entire set of objects in memory, or not stub out the child functions. If you don’t stub out the children, then you’re dependent upon a database and gold testing data. Suddenly, unit tests are quick and easy and you aren’t even really testing a unit anymore.
- Doesn’t work for data which morphs over time. Say you’re calculating something that depends on a time element. As time passes your unit test results will change naturally but your code which expected a certain result isn’t going to.
See, I said it was a short list. A better choice than not doing unit testing is, of course, to recognize these situations where unit testing benefits are outweighed by the downsides and to pick a different technique. I’m sure there are many more examples where the cost doesn’t justify the benefits. As LEAN thinking has been teaching for a long time – all work associated with defects (including inspecting for them) is waste and we should be seeking to minimize it, not make it our core strategy.