Listen to this post
TDD requires an expenditure of developer effort. All such effort is an investment, and thus should yield a return. TDD returns value in many ways, but here I will focus on one way in particular:
Tests prove their worth when they fail.
When a test fails, this is the point when we say “wow, we’re glad we wrote that test” because otherwise there would be a defect in the system that was undetected. But we can also ask how *much* value a test’s failure provides, and the answer is that the value is relative to the quality of the information it provides in that failure.
When a test fails for the reason it was intended to, this means several things:
- That intention was clearly understood when the test was written.
- That intention is clearly documented because of the way the test was written.
- The exact nature and location of the defect is made extremely clear.
Most developers will tell you that the tricky thing about debugging is not fixing the bug, but rather finding what and where it is in the code. Test that fail reliably for the reason they were intended to fail make the “find” much easier, and therefore reduce the cost of maintenance.