- 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.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.