My main response is that there's no "right" way to do TDD. There is a core definition, which is the red/green/refactor loop. New tests must fail; all tests must

My main response is that there's no "right" way to do TDD. There is a core definition, which is the red/green/refactor loop. New tests must fail; all tests must be green to refactor. Almost everything else is someone's interpretation. And, honestly, after enough time doing it you'll start taking careful shortcuts through the loop. (Am I allowed to say that in public? ;) Pairing in person with someone who's done it for a long time can help a lot, but even then you're getting someone's interpretation. If you worked with the DHH of three years ago, you'd get a very different interpretation (slower cycles, integration tests, no isolation) than if you worked with me (faster cycles, integration/unit mix, biased toward isolated unit tests). We were both doing TDD, though! (Given that he's said that he used to do TDD, I assume that he was following the core red/green/refactor loop.)