- Reduced Time in Up-Front Design
- Refactoring Versus Up-Front Design
- Reduced Time Producing Non-Executable Documentation
- Reduced Time in Reading/Updating Materials
- Less Time Wasted Reading Inaccurate Materials
- Reduced Debugging Time
- Reduced Number of Defects
- Reduced "Mulling" Time
- Reduced Amount of Code and Increased Reuse
- In Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Reduced Debugging Time
One very unpredictable cost of software development is the time we spend debugging code. In a typical system, the time between introduction of a defect and its discovery is usually considerable. It might be days, weeks, even months before we find defects. The problem with this time lag is that it makes the defects so much harder to fix. Two months later, or even two weeks later, we’ve forgotten everything about the piece of code that contains the problem. Worse, other developers may have added code around this area, and the combination of the original code plus the changed code is the true source of the problem.
With unit tests, we would normally discover the defect within minutes of introducing it. Pinpointing a defect introduced in 10 minutes’ worth of coding is reasonably easy. Worst case, we throw away the 10 minutes of test and code introduced. We start over, this time ensuring that we take even smaller steps before we get feedback. This practice allows us to identify precisely the point at which we introduced the defect.
I used to think that I was a pretty good coder. I would spend an afternoon slamming out code. I’d integrate the code and run some manual tests late in the afternoon. Sometimes it wouldn’t work—imagine that! I’d then be forced to spend another few hours unraveling the mess I’d built. In some cases, I had introduced the problem in the first few minutes of coding.
TDD will help keep you from going too far down these ratholes!