: R. Jeffries and G. MelnikVenue
: IEEE SoftwareDate
: May-June 2007
This article is a guest editor introduction to IEEE Software. It is a survey of the current state of the art of TDD. It covers both academia and industry.
TDD gives programmers more confidence in changing code. This is because if you break something unrelated the current piece of the project you are working on, TDD's regression tests will catch it, so when it passes successfully, the user is more confident in its robustness. As programmers build confidence, they can relax as they work. The software development community finds TDD to be a fast way to develop reliable code, once you are "test-infected" and in the rhythm of TDD. Continues design changes in Agile development brings the risk of breaking code, but TDD allows us to keep a sharp eye on this risk.
In general, many studies don't have statistical power to allow for generalizations for TDD's effects, so every study surveyed had to be taken within each study's context and environment.
The most common measurements taken was the change in productivity and the quality effect. Again, each study compared TDD to another method, whether it was test-last, or iterative-test-last, or no testing at all can differ between studies, so results MUST be taken within context. However, eight of the ten studies in Industry found significant drops in internal defect density, from 40%-80%. Productivity however, mainly decreased because it took more time to develop. Most rates of increased effort were between 5%-35%.
The academic measurements taken into consideration for comparison were also productivity and quality effect. The results with student studies were back and forth. Some studies were successful in improving productivity, others weren't. Some studies improved the quality of code, and others didn't. There are so many factors when trying to conduct a study in academia, that it seems expected to have such varied results.