3 ms·

> Classical TDD does not involve mocking or other forms of synthetic isolation by definition. We even use the term "classical TDD" to mean "TDD without isolatio

by tieTYT 12y ago

> Classical TDD does not involve mocking or other forms of synthetic isolation by definition. We even use the term "classical TDD" to mean "TDD without isolation". I wish there was a source on this paragraph. According to this talk that often refers to Kent Beck's book ( the talk: http://vimeo.com/68375232 http://vimeo.com/68375232 / a good summary of the talk, in text: https://groups.google.com/forum/#!topic/growing-object-oriented-software/Hxp8cVfE4gI https://groups.google.com/forum/#!topic/growing-object-orien... ), you are supposed to isolate from the database.

gary_bernhardt 12y ago
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.
- ssmoot 12y ago
  At least in .NET land stubs were very common (several libraries actually generated them for you based on your Interfaces). Nice post BTW.
- tieTYT 12y ago
  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. The thing I don't like about TDD is I never know if I'm doing it correctly. There's always that No True Scotsman fallacy^1 situation. "Oh, you tried TDD and it didn't work out for you? If you were doing real TDD it would have worked out." And I say this as a person who has watched three of Uncle Bob's videos on TDD that you have to pay for: http://cleancoders.com/episode/clean-code-episode-6-p1/show http://cleancoders.com/episode/clean-code-episode-6-p1/show http://cleancoders.com/episode/clean-code-episode-6-p2/show http://cleancoders.com/episode/clean-code-episode-6-p2/show http://cleancoders.com/episode/clean-code-episode-19-p1/show http://cleancoders.com/episode/clean-code-episode-19-p1/show 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. ^1: http://rationalwiki.org/wiki/No_True_Scotsman http://rationalwiki.org/wiki/No_True_Scotsman EDIT: Sorry, I commented as I read. Looks like you're going to explain it in the article.
  - gary_bernhardt 12y ago
    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.)

by tieTYT 12y ago

gary_bernhardt 12y ago

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.

ssmoot 12y ago
At least in .NET land stubs were very common (several libraries actually generated them for you based on your Interfaces). Nice post BTW.
tieTYT 12y ago
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. The thing I don't like about TDD is I never know if I'm doing it correctly. There's always that No True Scotsman fallacy^1 situation. "Oh, you tried TDD and it didn't work out for you? If you were doing real TDD it would have worked out." And I say this as a person who has watched three of Uncle Bob's videos on TDD that you have to pay for: http://cleancoders.com/episode/clean-code-episode-6-p1/show http://cleancoders.com/episode/clean-code-episode-6-p1/show http://cleancoders.com/episode/clean-code-episode-6-p2/show http://cleancoders.com/episode/clean-code-episode-6-p2/show http://cleancoders.com/episode/clean-code-episode-19-p1/show http://cleancoders.com/episode/clean-code-episode-19-p1/show 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. ^1: http://rationalwiki.org/wiki/No_True_Scotsman http://rationalwiki.org/wiki/No_True_Scotsman EDIT: Sorry, I commented as I read. Looks like you're going to explain it in the article.
- gary_bernhardt 12y ago
  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.)