I ran across this little gem recently. It's about 40 minutes long, and full of great insights into unit testing.
To unjustly summarize, there are several points along the spectrum of unit testing:
- No testing
- Manual testing
- Test-after unit testing
- Test-first unit testing
- TDD Test-driven-development
- TDD Test-driven-design
The sweet spot seems to be in going back and forth between TDD and TDD. However, it takes a good amount of time and effort to be able to recognize where you are on this spectrum, or that there even is a spectrum of testing.
Test-driven-design is a tool to help you work out the classes involved in your solution, and how they will work together. This can be likened to the old school technique of designing your interface.
Test-driven-development is a tool to bullet-proof your code; to test the edge-cases; to test for boundary values; and generally to make sure that your code works in as many situations as possible. This can be likened to the old school technique of fleshing out your implementation.
It takes great skill to work back and forth between these two flavors of of TDD. Yet by getting to that point, in addition to a solid design and a solid implementation, you'll have the safety net in place to be aggressive, make changes, and respond to your clients needs.
You may even quickly deliver valuable features. What could be better than that?
Post a Comment