- Reduced Time in Up-Front Design
- Refactoring Versus Up-Front Design
- Reduced Time Producing Non-Executable Documentation
- Reduced Time in Reading/Updating Materials
- Less Time Wasted Reading Inaccurate Materials
- Reduced Debugging Time
- Reduced Number of Defects
- Reduced "Mulling" Time
- Reduced Amount of Code and Increased Reuse
- In Conclusion
Reduced Number of Defects
Any defect is costly. Even with a perfect up-front design, it’s still possible to introduce defects that are very difficult to figure out.
With TDD, every piece of code exists because it was required by a test. That rule, in turn, means that we have solid unit test coverage. (We don’t have exhaustive coverage, which would be virtually impossible to provide.) Defect rates should come down significantly. Martin Fowler and Ron Jeffries talk about shops that severely reduced their numbers of defects. Most teams working on moderate-sized applications (several hundred thousand lines of code) have defect rates in the hundreds or even thousands per year. Shops doing TDD can achieve rates of less than a dozen per year (but they probably need to be adhering to other proven disciplines as well).