Kent Beck, the creator of Test-Driven Development, had a rejoinder and since then, they and Martin Fowler, another respected name in quality software design, have engaged in a serial public conversation.
We've watched videos of their first two conversations for our weekly Learning Lunch. There will be more sessions coming soon but in the meantime I'll offer my thoughts and observations.
In the first session there was some useful clarification of terms. Test-Driven Development is different from self-testing code. Everyone agreed that code should be fully tested and self-testing. Most of the complaints David raised with TDD Kent said were not actually part of the definition of Test-Driven Development.
Test-Driven Development doesn't depend on heavy use of mocks and it shouldn't be used all the time. It's a tool to apply when appropriate, not a moral imperative.
In the second session the main topic was David's claim that TDD leads to design damage. Kent's reply was that Test-Driven Development may put evolutionary pressures on your design, but ultimately it's up to the programmer to make decisions that improve or damage the software's design.
The takeaway for me was when Kent said good design will be easily testable. Approach the problem with the goal of making your design good rather than making it testable, it'll end up just as easy to test.
The end of the second session included a dismissal by David of "faith-based TDD". Kent had a good reply, but I think the crux of the discussion is given away in David's keynote. When David uses the abbreviation TDD he means Test-Driven Design, not Development.
Kent and Martin explained why a number of David's complaints aren't to do with Test-Driven Development, but David isn't acutally complaining about Test-Driven Development.
Test-Driven Design seems to be an extension of Test-Driven Development that sets the goal of making your design testable instead of making it good.
The distinction in terms wasn't explicitly mentioned but I think it was the cause of their talking past each other and my feeling that Kent and Martin failed to convince David.
The general sentiment of our development team is you learn the right way with experience. At Resolve each of us has certain strengths so we're always able to get or give feedback. That feedback process is in high gear when we pair program. We're also fully on-board with self-testing code.
Whether we're augmenting your team or working on a brand new app, I think we use Test-Driven Development when it's appropriate. But it's always good to listen to the masters like Kent and Martin to make sure.
Read this related post on testing and the importance of a testing culture.
Join The Conversation
More On The Blog
Why is it so hard to get an estimate for a software product?
Getting an accurate estimation for your software product can save you time, money and countless headaches when building your site, MVP or product.
David Hemmat — May 20, 2021
What open source can offer eCommerce sites.
In this article we will be looking at the most typical categories to choose from and giving you our take on what open source can do for your brand.
Alejandra Renteria — Sep 24, 2020
Grocery eCommerce: insights for the future of supermarkets.
In this article we'll take a closer look at trends and success factors driving the grocery eCommerce industry forward.
Alejandra Renteria — Sep 22, 2020