In the November/December issue of IEEE Software the Voice of Evidence addresses Test Driven Development (TDD). Researcher Forrest Shull and several colleagues have reviewed the research literature on TDD. They posed three questions:
- Does TDD improve delivered quality?
- Does TDD improve internal code quality?
- Does TDD improve productivity?
They found 22 articles describing 33 individual studies. These studies were classified based on their “rigor”. The conclusions below are based on how many high rigor studies supported it or opposed it. Lower rigor studies and inconclusive evidence is not considered.
TDD does improve software quality with 5 favorable studies and 2 negative. There may be some confounding effects of expertise here. In my experience, better programmers are also more likely to embrace TDD. Nevertheless, it is hard for me to see how more testing could lead to worse software.
There is no evidence (2.5 versus 2.5) that TDD leads to better internal code quality. This does not correspond to my personal experience. From what I have seen TDD will force higher modularity, testability and forcing the programmer to think first etc which will all favor better code.
TDD leads to higher productivity (6 versus 4). I have previously argued, in “Does unit testing pay off?“, that just by reducing the number of bug fixes developers should be able to free up substantial productive hours.
Counting studies as if science was a democracy and studies had a vote strikes me as less than rigorous but together with all the previous evidence to support test driven development be it test-first or test-last this is just another reason for all those who have not already done so to take a serious look at TDD and see what you can learn from it. Especially now, when a strong unit test suite can even help you to auto-fix your bugs.