(I originally posted this on my MSDN blog.)
Someone asked a question on an internal distribution list to the effect of:
“My team is thinking about making unit testing a standard practice. The technical benefits are obvious, but management is asking questions about the impact to the business. How badly will productivity suffer in the short term? What’s the ROI of unit testing? Are there metrics or published studies I can use?”
My answer:
You may be able to find some hard statistics in various reports, but practical problem is that the variance from team to team can be huge so there’s no way to take the results from some other team and use it to predict with any accuracy what will happen to your team. There are a couple of things that can be said with certainty.
First, introducing unit testing will decrease your team’s productivity in the short term, no question. By how much? That depends on the team and how much they resist learning new ways of doing things, and it also depends on management and how much they really mean it when they say they want developers to write unit tests and they’re willing to pay the upfront cost. The transition could go relatively smoothly or it could be really ugly depending on how cooperative people are feeling.
It also depends heavily on the existing architecture of your code. Effective unit testing requires your code to be organized according to basic principles of good architecture; i.e. high cohesion, loose coupling, and everything that goes along with that. There’s nothing like unit testing to point out that your supposedly good architecture is actually terrible. Introducing unit testing may ultimately mean a lot of refactoring of your existing code. It doesn’t have to happen all at once but it may have to happen at some point.
Second, the payoff won’t be felt in the short term. The payoff is long-term after you get your architecture straightened out, after you have a good base of unit tests, and after everyone gets fully on board with the new way of doing things. Then you’ll see fewer bugs being written in new code, fewer regression bugs in old code, and less incremental cost for adding or changing features. Your code base won’t “rot” as fast.
Unfortunately the value here is difficult to quantify in hard numbers. The amount of value you earn back depends largely on whether the team is honestly committed to unit testing or if they’re just paying lip service to it, and it depends on whether you’re doing unit testing correctly or not. It’s certainly possible to write unit tests badly just like it’s possible to write code badly. If at all possible you should invest in bringing in an experienced unit testing expert who can show you how to do it correctly and what pitfalls to avoid.
SaintGimp 