Test-driven development (and test-driven design, behavior-driven design, acceptance test-driven development, etc.) have been around a while. One might say that it was started (or “rediscovered“) in 2003 with the publication of Kent Beck’s book “Test-Driven Development By Example.”
Whilst there are purist arguments about whether strictly adopting TDD is the best approach, there are few arguments about whether it is wise to adopt the general philosophy. Why? Because the earlier a defect is detected, the cheaper it is to fix it.
In Code Complete: A Practical Handbook of Software Construction, Steve McConnell provides estimates of the cost to remediate a defect in table 3-1 “Average Cost of Fixing Defects Based on When They’re Introduced and Detected” (page 29 in the second edition of the book, near the beginning of chapter 3).
This table makes it pretty clear that non-coding bugs need to be detected before coding begins, and coding bugs need to be detected before a project reaches the system test stage. From these points hereafter the cost of defect resolution rises drastically.
So how does one ensure that defects are detected at these early stages?
Well the TDD philosophy is by far the most effective method. Particularly when supported by organizational/cultural factors such as co-location and multi-disciplinary team working.
TDD is not the golden ticket. Implementing TDD will not result in 100% bug-free code delivered at the minimum possible cost. But it will increase quality and value-for-money.
But TDD should not be utilized blindly.
It can become a cult and eventually stifle the development effort. It can also overemphasize unit testing at the expense of system testing. As with all ideas, proponents can lose the big picture view, and focus on deviations for a purist TDD approach when it is pragmatic to employ a hybrid approach that conforms to the “quality to the left” ideal but doesn’t require a Stalinist adherence to every TDD rule.
Steve McConnell references the following sources:
- Design and Code Inspections to Reduce Errors in Program Development (Fagan 1976)
- Software Defect Removal (Dunn 1984)
- Software Process Improvement at Hughes Aircraft (Humphrey, Snyder, and Willis 1991)
- Calculating the Return on Investment from More Effective Requirements Management (Leffingwell 1997)
- Hughes Aircraft’s Widespread Deployment of a Continuously Improving Software Process (Willis et al. 1998)
- An Economic Release Decision Model: Insights into Software Project Management (Grady 1999)
- What We Have Learned About Fighting Defects (Shull et al. 2002)
- Balancing Agility and Discipline: A Guide for the Perplexed (Boehm and Turner 2004)