You’ve already heard of Test-Driven Development. Finally, you get down to trying it out for real. You even manage to convince your whole team to adopt it with you. Now you ask yourself how to find out, whether TDD actually benefits your team.
Here's the comprehensive blog What is TDD? to know more about Test-driven development.
One of the primary reasons managers cite for waiting so long to implement TDD is the cost. It’s common for the initial project build-outs to take up to 30% longer with TDD.
What those managers need to know is that TDD reduces production bug density 40% — 80%, and that makes all the difference. More bugs in production leads to a dramatic rise in maintenance costs.
Before adopting TDD, we ran a small survey project with and without TDD. There were 4 developers working on each project with an average salary of $150. Here are the results of each project.
Without TDD:
No. of man-hours to complete a project: 200 hours
No. of production bugs without TDD: 70
Average time to fix bug at production: 4 hours
Total hours: 200 + (70x4=280) = 480 hours
With TDD:
No. of man-hours to complete a project: 240 hours
No. of production bugs without TDD: 70
Average time to fix bug at the implementation: 1 hour
Total hours: 240+70 = 310 hours
We saved 480-310= 170 hours X $150/hour = $ 25500.
Why cost of fixing production bugs is less in TDD?
In TDD, your team can maintain a stable code base throughout the development lifecycle. By properly creating tests first, and then writing code that passes those tests, the chances of regressive bugs popping up drops dramatically.
On the other hand, in traditional approach cost of fixing production bugs is high because developers are pulled out of the context in which they’re currently working and dumped into the context of the bug. It takes time to absorb the related code and flow, diagnose a root cause, fix the bug, and then reabsorb the context of what they were working on before.
In other words, the cost of fixing bugs that get released in production isn’t just about the cost of fixing the production bug. Interruptions increase the cost of current development work and introduce more bugs that will eventually need fixing, too.
What is your experience with TDD in terms of cost and development time?
Top comments (3)
Yeah, those time-to-fix-bug numbers are definitely where TDD is going to shine. And that number probably only grows wider as a codebase grows. Codebases with good tests and good testing culture are going to improve or stay the same in this regard. Definitely not the case for the other kind.
Exactly, time-to-fix-bug is less because, in TDD, we should never write more production code than it is necessary to pass the currently failing unit test. This has profound implications. We don't have to think about the whole implementation upfront. We let the tests guide us.
Hi Kalpesh, your article is impressive and we would like to translate into Japanese and post it in our website to share with our readers.
Will that be ok? For more detail, please see postd.cc/hello/ Looking forward to hearing from you.