''reposted without permission from the XP Mailing List'' Quoting Roy Osherove "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