Let’s start with a few statistics to give you an overview of the value TDD brings to enterprise development initiatives.
- Debugging software takes 620 million developer hours each year, costing around $61 billion.
- Developers spend 10 times more time reading code than writing.
- The average time required to fix a software error is 13 hours.
- The cost of fixing system failures during testing can be 15X more than fixing them during design/implementation.
But what if we tell you there is a modern technique of agile software development to address these challenges? A rule of thumb so efficient that it virtually eliminates the need for debugging or notifies you about coding errors right after you made them?
Introducing Test Driven Development, where you write tests before the code itself!
Remember those days of punch cards when developers had to painfully hand-check each and every line of code to ensure seamless compilation. A compile error meant they must go through an extreme debugging session to find out the mislaid character.
However, compiling code is not a big deal today as IDEs (Integrated Development Environments) provide a fast feedback loop to find and fix errors easily.
TDD does the same by cranking up the feedback on code execution and looking into the syntax as you type. Every few minutes, or even every 20/30 seconds, you can verify that the code is doing what it should do. And if there is an error, you need to check only a few lines of code.
The concept is similar to double-entry bookkeeping. You get to define the same idea twice but in different ways — first with the test and then with the code. Programmers have coded both of them correctly if they match. And if they do not, there is an error somewhere.
Despite everything, TDD in agile is not all about testing. The proposition behind it is that you should continuously test and refactor all code. But those tests are not the whole point of this software development life cycle methodology; the ultimate goal is to achieve three important things by writing tests first and keeping them easy to write:
- Building a safety net to confidently implement changes.
- Designing/redesigning code to be clean, readable, and uncomplicated so that it is easily testable.
- Creating comprehensive specifications with forever-relevant documentation.
