Well, like I say in the post, mocks didn't exist back then, so they couldn't have been mocking in the sense that we are now. I wasn't there, but I believe it's true that in some cases they were doing what we'd now consider "fakes", which are simplified replacements for production dependencies that have minimal working implementations. (An in-memory database is an example.)
Fakes get you around the question of database integration, but not the question of integration in general. You'd have to create a fake of every class in the system for that, in which case you probably just re-invented mocks and/or stubs.
I probably could've more explicitly called out the fact that DHH is obsessing over database integration when it's just a special case of what isolated testers are actually worried about, which is integration in general. It was already a long post, though.
Thanks for the reply and for the article. I took your quote out of context. I'm not very interested in DHH's mis/understanding of TDD. I'm more interested in my understanding of TDD. I'm trying to figure out if I'm doing TDD correctly or incorrectly when I isolate the database. Whether it's done through a mock or a fake or whatever is not that important to me.
Sorry for hijacking the topic. I've been trying TDD for years, and I never know if I'm doing it correctly. I saw this line and it made me question it yet again.
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.)
Fakes get you around the question of database integration, but not the question of integration in general. You'd have to create a fake of every class in the system for that, in which case you probably just re-invented mocks and/or stubs.
I probably could've more explicitly called out the fact that DHH is obsessing over database integration when it's just a special case of what isolated testers are actually worried about, which is integration in general. It was already a long post, though.