Published in IEEE Software, Volume 25, Issue 2, March 1, 2008, pages 77-84.
Copyright 2008 IEEE.
The definitive version is available at http://dx.doi.org/10.1109/MS.2008.34.
Software developers are known for adopting new technologies and practices on the basis of their novelty or anecdotal evidence of their promise. Who can blame them? With constant pressure to produce more with less, we often can’t wait for evidence before jumping in. We become convinced that competition won’t let us wait. Advocates for test-driven development claim that TDD produces code that’s simpler, more cohesive, and less coupled than code developed in a more traditional test-last way. Support for TDD is growing in many development contexts beyond its common association with Extreme Programming. Examples such as Robert C. Martin’s bowling game demonstrate the clean and sometimes surprising designs that can emerge with TDD,1 and the buzz has proven sufficient for many software developers to try it. Positive personal experiences have led many to add TDD to their list of “best practices,” but for others, the jury is still out. And although the literature includes many publications that teach us how to do TDD, it includes less empirical evaluation of the results. In 2004, we began a study to collect evidence that would substantiate or question the claims regarding TDD’s influence on software.