- 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
Reduced Time in Reading/Updating Materials
If non-executable documents exist, it takes time for me to locate them and then find the sections that I need to read. If they’re poorly written, I might have to read the material a few times before I understand it. Certainly, this statement can also be true of code, but if you’re following the TDD concepts I’ve covered in this series, your code should be much clearer.
Non-executable documents can’t easily be linked to code. With TDD, I can use the tests to comprehend the system. Once I find a pertinent area, I can navigate directly from the test specification into the system. (In Eclipse, it’s as simple as pressing F3.) Without TDD, I have to spend time reaching for the binder—either physically or on disk, by digging through folders and opening files.