Writing Tests Slows Me Down
Explore the reasons behind the common myth that writing tests slows down development in test-driven development (TDD). Understand how investing time in automated testing early leads to fewer defects, reduces manual testing effort, and prevents costly rework. Learn to quantify the overall time and cost benefits of TDD versus no or manual testing approaches.
Writing tests that slow development down is a popular complaint about TDD. This criticism has some merit. Personally, we’ve only ever felt that TDD has made me faster, but academic research disagrees. A meta-analysis of 18 primary studies by the Association for Computing Machinery showed that TDD did improve productivity in academic settings but added extra time in industrial contexts. However, that’s not the full story.
Understanding the benefits of slowing down
The aforementioned research indicates that the payback for taking extra time with TDD is a reduction in the number of defects that go live in the software. With TDD, these defects are identified and eliminated far sooner than with other approaches. By resolving issues before manual quality assurance (QA), deployment, and release, and before potentially facing a bug report from an end user, TDD allows us to cut out a large chunk of that wasted effort. We can see the difference in the amount of work to be done in this figure:
The top row represents developing a feature using TDD, where we have sufficient tests to prevent any defects from going into production. The bottom row represents developing the same feature in a ...