In the first of the #IsTDDDead video series, David Heinemeier Hansson, introduces the friendly debate declaring “there will be no boxing”. And indeed the Queensbury rules were not needed for this debate as the gloves came off with DHH declaring TDD “a big bowl of shit!”

Martin Fowler and Kent Beck were both pretty much floored by this comment, with the only hint of any retaliation being that they would continue to talk more about it in the next episode.

Now that the initial sensationalism is out of the way, I’m going to summarise the video for you. Many people don’t have a spare half an hour so you can save yourself about 25 minutes by reading this summary below:

Friendly Debate Summary

DHH introduces by listing his three main gripes with TDD
1. Definition of TDD and its components especially unit testing – can’t touch collaborators e.g. database, file system
2. Mock heavy architectures and hexagon architectures are “not very great at all” and “Test induced damage”
3. Red green refactor loop – too much of a mandate. Sometimes works but often not for DHH

Kent Beck wrote SUnit for SmallTalk which was the precursor to JUnit and NUnit. He explains that one of his heuristics is “if an idea is obviously bad, find a cheap way to try it because if it turns out it’s not bad then it’s really interesting” which is why he first tried TDD, and says he has a lot of anxiety and gets overwhelmed by big problems and finds TDD solves them by letting him break problems into smaller pieces. Kent likes to develop bottom up.

Kent says that TDD is one way to help developers feel more confident, instead of writing stuff and just hoping it works and then worrying that you might have broken something.

DHH says Ruby’s mission statement is programmer happiness and related to confidence in code but only one part of the picture and that he never got a good feeling from doing TDD. He finds it unnatural and not a pleasurable flow. He thinks different brain styles determine people’s preference for or against TDD.

Kent says at the last hackathon he went to half the code was TDD friendly and half wasn’t and prefers to work with TDD friendly code but understands “not everybody’s like that”

DHH poses the question “what am I will to sacrifice in order to do test driven development?” And says he’s not willing to sacrifice that much. He criticises “nasty hacks” in order to do TDD.

Kent says “it’s a question of trade offs” and that understanding how to design things well is a big factor. He finds that bad design is usually related to poor testability. He doesn’t use mocks very often. He’s found bad unit testing code with mocks returning mocks returning mocks which is not good practice at all because it hinders refactoring instead of enabling it.

Martin says there are about 24 different definitions of unit testing. He agrees that he doesn’t use mocks much but says some good developers do. He finds having self testing code is really important and powerful, but says TDD is only one approach to self testing code. He’s happy with test after development (writing unit tests after the production code)

DHH criticises TDD talks equating TDD and professionalism, the notion that self testing code is less important than driving you code through TDD, and the notion that you can’t improve design without TDD. He says he seen code full of three streets of mocks because unit testing was applied to areas of code that didn’t fit it well. He says really useful patterns and technologies such as Active Directory have been discarded because they’re not TDD friendly. He talks of developers throwing away useful work in favour of worshipping at the altar of test driven design.

DHH complains about disparate concepts such as self tested code, red green refactor, mocks all being thrown into the same TDD pot.
He says there are more important principles than whether the code is testable: is it clear? is it understandable?

Martin finishes by saying they’ve run out of time but that we should explore the questions “In what ways can a desire to do TDD damage an architecture?” and “Is it damage?” and says the next episode will explore hexagonal rails architecture versus what some people would say “that crap David is talking about”

Brief Editorial

Round one goes to David Heinemeier Hansson. However I have a feeling that some of the future rounds won’t be so easy.

It is good to see that despite retaining the #isTDDdead title, the debate has moved passed the dead/not dead pantomine and onto what the trade offs are. There weren’t any satisfactory answers to that yet but they will be several more debates to come that should cover that subject in a little more depth. Have your say on this debate below: