cashto emphasized that unit testing is useful for teams with non-expert programmers (viz. his comment about the Dreyfus model of skill acquisition). Many of us are non-experts who benefit from working with the TDD training wheels on; it's O.K. to be less a Jedi All-Star hacker. But the phenomenal programmers, the men and women who were 10 times better than me, could not be bothered with TDD, even through the endorsed it for mere mortals.

To paraphrase the TDD credo of “no test is worse than having no tests”, we can assert that blind faith is not better than no faith at all.

I also notice reference to writing tests after the fact. I understand TDD to involve writing tests first. That's how I practice it anyway.

My experiences are the same as yours. I've refactored code where the unit tests caught that the new structure introduced subtle logical inconsistencies in the program. The unit tests meant I caught this immediately; without them I would have had to wait until subtle and hard-to-fix bugs emerged.

On a different project, I've been able to play around with the structure of the code, secure in the knowledge that my regression test suite will tell me when I fuck things up.

Tests, when done well, are a lifesaver, and essential to any large complex codebase.

> But these are points that belong in a serious discussion, the kind that recognizes tradeoffs.

Exactly.

Here we see the risk of asserting something isn't real just because we haven't ourselves seen it. I've held a bat in my hands, and I've had my butt saved countless times by tests I've written.