Why we Test, part 7, The Dead Horse

I've seen a wide range of practices that the practitioner claimed was TDD. (Arlo Belshee identifies 7). Obviously, outcomes vary.

People claimed that TDD was or was not effective in some way based on those results. To make it worse, I see wide variation in the stated purpose of TDD. If we don't see the same purpose, then we aren't measuring effectiveness the same way. For example:

1. ensure correctness of new code
2. prevent regressions due to future work
3. point me directly at my mistake
4. be fast enough to run often
5. a safety net during refactoring
6. the only way to be sure my tests are comprehensive
7. to stop me from writing code I don't need
8. make code coupling obvious
9. make DRY problems visible
10. support cohesion
11. create the context for entering a Flow state
12. regular rewards as I make progress
13. confidence (possibly false!) that my program will work
14. explain to another human what my code is intended to do

(I sometimes group these into Bugs, Design Feedback, Psychological Benefits, and Specification.)

If you start by practicing TDD a certain way, and see it succeed at one of the above, you'll be tempted to argue that is the "true purpose" of TDD.

If you start with a belief about the true purpose of TDD, and select a practice that doesn't do that, you'll think TDD doesn't work. (See We Tried Baseball...)

I say all this because I hope people will shift to an "all of the above" mindset, and adjust their understanding and practice to make that happen.