reposted without permission from the XP Mailing List
Quoting Roy Osherove
<http://weblogs.asp.net/rosherove/articles/Design4Tesatbility1.aspx>
"Here's my current definition of a testable system:
"For each logical part of the system, a unit test can be written
relatively easily and quickly that satisfies all the following PC-COF
rules at the same time:
- "[1] Partial runs are possible
- [2] Consistent results on every test run
- [3]Configuration is unneeded before run
- [4]Order of tests does not matter
- [5]Fast run time"
If a system is grown through
TestDrivenDevelopment, then...
- [1] partial runs are inevitable,
- [2] consistent results should happen (if standard TDD advice about avoiding globals, side-effects, live network connections / databases, are followed).
- [3] Configuration should be in the tests rather than outside of the framework,
- [4] Order of the tests should not matter (again, standard TDD advice), and
- [5] the tests should run quickly (standard TDD advice again).
So I don't think any *additional* advice regarding testability is
necessary for people practicing TDD.
If you want to motivate testability for code developed without the
benefit of TDD, that's a fine goal.... but shouldn't really be
confused with TDD. MichaelFeather?'s WorkingEffectivelyWithLegacyCode covered that, and the mailing list associated with the book is still around, though inactive. Search for WELC.
C. Keith Ray