Tuesday, September 30, 2008
TDD vs TAD (Test After Development)
TDD offers the following benefits:
- Bugs are prevented or found early. Finding bugs late is expensive!
- Refactoring can be done with confidence. If the code has proper test coverage, it is unlikely that future refactorings will break it.
- Thinking of and designing for edge cases up front promotes a better and more stable design.
- One is forced to think about how the code will be used first, which should lead to code that actually meets its requirements.
- Less code! TDD is usually coupled with DTSTTCPW.
Theoretically, TAD applies to 2 and maybe 1. In practice, is this really the case? In my experience TAD is far inferior to TDD because its execution is sub par in the following ways:
- Many TAD project just test the "complex" parts of the code.
- Most TAD projects start out well, but end up with unit tests that just increase code coverage with little thought to quality.
- Testing after development requires the developer to figure out the intent of the code again.
- TAD does not benefit from 3, 4, and 5 above.
Subscribe to Posts [Atom]