This entire debate would not have occurred if DHH had read this quote by Matsuo Basho:
Do not seek to follow in the footsteps of the wise. Seek what they sought.
David's objections:
- Unnecessary indirection and complexity required to make it easier to test in isolation.
- Using mocks to isolate from external dependencies
The design David showed wasn't due to TDD, the real issue is that these indirections are all good tricks under some circumstances and we need to understand whether they are worth the cost or not.
Kent said that developers' make one design decision at a time. TDD puts an evolutionary pressure on a design, people have different preferences for the grain-size of how much is covered by their tests. David replied that there's a direct correlation between the size of code and how easy it is to change it.
David said the reason people wanted isolation was due to TDD. You can't just swap out an in-memory store for a call to a web service because they have different operational characteristics. These swap-ability pipe-dreams aren't the real goal - the real goal is isolated testing. Kent agreed that you can't treat in-memory and web services the same as the failure cases are different. The boundaries between elements will leak to some degree "the question is how much are we willing to spend to get how much decoupling between elements".
Kent saw the difference between 10 lines of code and 60 as a cohesion issue. David agreed but argued that cohesion and coupling are often opposed. Higher coupling is usually worth the price to get better cohesion. Kent observed that there are other ways to eliminate external dependencies, you can also use intermediate results, this is what happens with compilers.
Something that's hard to test is an indication that you need a design insight, it's often useful to get up and take a walk to find those insights that lead to better designs that are also more testable.
Kent clarified he wasn't talking about TDD, but about software design in general, it's not about TDD it's about how to get feedback. Thinking about software design is the thing, because it pays off so big when you get a good design insight. Getting these insights isn't about your workflow, it's about things like knowing when to work and when to rest, gathering influences from other places, collaborating with other people.
Executive Summary
DHH is not seeking what Kent Beck is after:
- Fast Feedback Loop
- Cheap Way to Test Ideas
- Gaining Confidence
Reference
