- #1: Build Classes, Not Individual Databases
- #2: Don't Ignore History
- #3: Automate All Changes to Every Database Instance
- #4: Test Every Change to Database Design
- #5: Force Clients to Break Fast When Interfaces Change
- #6: Encapsulate Database Behavior
- #7: Drive Behavior from Information
- #8: Keep a Complete Unit Test Suite
- #9: Build Only What You Need
- #10: DON'T PANIC
- Summary
#8: Keep a Complete Unit Test Suite
TDD does a lot to support an agile environment. It helps you think about the problem you are solving in an interesting way. It helps you communicate the design decisions you’ve made. It forces you to think about a class from the perspective of its clients first and in terms of its private implementation details second.
All of those benefits are individually great. Together, they are really helpful. However, if you combine together the value of every benefit of TDD save for one, the resulting sum would still be far outweighed by the simple fact that TDD drives automated test coverage up to nearly 100%. Having a test becomes the rule and not having one becomes an exception that requires a very good explanation.
A full panel of unit tests for a database design–or any design, really—will tell you in seconds or minutes if you have unintentionally broken an existing behavior. That short cycle is paramount because the cost of fixing a defect is related to the delay between when you introduce it and when you find it. If it’s only been a few minutes, the repairs are easy or trivial. If it’s been a few weeks, the repairs are hard and sometimes even border on impossible.
Furthermore, with a test for every behavior in your database design, you can keep your class of databases in full working order and, therefore, releasable at all times. Keeping your software—all your software—working and bug free at all times is essential to supporting an agile process. In fact, it is part of the very definition of one.