At the annual Ruby on Rails conference, David Heinemeier Hansson, the creator of Rails, sparked a storm in his keynote and blog post titled "TDD is dead. Long live testing."

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.