- 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
In Conclusion
My preceding comments are based on doing TDD for about seven years. I’ve compared it to how I used to build software, and to how other shops and people build software. But you won’t see these kinds of benefits if you don’t do TDD properly. Learning to do TDD properly is not complex, but it’s hard to maintain the necessary discipline. To do TDD right, you must follow some very simple rules:
- Always write tests in order to drive out code.
- Always ensure that every time you introduce new code, you fix anything it did to negatively impact the design.
- Take small, small steps!
Some caveats: You’ll continue to have some productivity hits along the way. Some of these will occur because you’re trying to learn how to test something different. For example, we haven’t touched web applications yet. How might we test web applications?
You might also realize that the code is becoming more brittle—more resistant to change. Usually this is a sign that you haven’t been refactoring as vehemently as you should. Go back to the simple rules of TDD. Consider pair programming to help enforce adherence to the practice.
You’ll certainly take an initial productivity hit while you’re learning TDD. But that’s expected of any discipline. Soon the practice will be ingrained and you won’t have to think about it. Then you should start to experience a faster rate of development.
Test-driven development is not a silver bullet. It won’t cure diseases, and it won’t always keep you from doing bad things to your system. But you should recognize its potential value as a tool. Invest an appropriate amount of time to see how beneficial TDD can be for you.
You may end up wondering how you ever did without TDD. Some people like to use the term "test infected" to describe how most developers end up getting addicted to TDD. I’m infected! As Jerry Jackson said (see installment 12), "We could tell that there was no going back."
I’ve enjoyed working with you to build this application. Now...go finish it!