- 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 Amount of Code and Increased Reuse
Without TDD, it’s unsafe to refactor. Therefore we don’t do it—"If it ain’t broke, don’t fix it." The result is that many bad things happen to code. No one cleans up rampant duplication. No one corrects code that’s difficult to read and maintain.
TDD enables refactoring. That’s extremely significant. We can now keep the code clean and duplication-free. That change, in turn, speeds up the overall rate of development. We shrink the overall amount of code required. We also start to see a lot more reuse at both the method and class levels.
A lot of the duplication in a system isn’t evident until you start refactoring. Once you begin refactoring, you start recognizing potential for reuse. You’re more likely to recognize that a small, newly extracted method could be called by another method, which in turn simplifies the other method. You start to build simpler classes that do fewer things. Often, having a smaller class increases the likelihood that other classes can reuse it.