- Writing tests first require you to really consider what you want from the code
- Short feedback loop
- Creates a detailed specification
- Reduced time in rework
- Less time spent in the debugger and when it is required you usually get closer to problem quickly
- Tells you whether your last change (or refactoring) has broken previously working code
- Allows the design to evolve and adapt to your changing understanding of the problem.
- The resulting Unit Tests are simple and act as documentation for the code
- Improves quality and reduces bugs by:
- forcing us to consider purpose (and the specification of code)
- simplifying code (many bugs come from the complexity)
- ensuring changes and new code don’t break the expectations of existing code
TDD is hard to learn, especially on your own. You can expect reduced productivity for 2-4 months after starting.
Other articles that discuss the benefits of TDD: Twelve Benefits of Unit Tests, Research Supports The Effectiveness of TDD, TDD Research Findings, How TDD improves development speed and is very cost effective, Test Driven Development Requires Less Debugging, The Benefits of Test-Driven Development
Finally as I stated at the time I believe that these benefits can’t be achieved by writing tests after the fact.
Next up will be a short item outlining a one possible TDD adoption strategy.