The failures of introducing test driven development
I’m now halfway through teaching a two-week crash course on “agile development stuff” to a team of very traditional enterprise Java developers. Condensing fifteen years of our community’s progress into 8 half-day workshops has presented an obvious challenge: given the clear time constraints, what set of ideas and practices could conceivably have the biggest positive impact on these developers’ professional lives?
After a few days of fits and starts, I’ve come to at least one realization: Test-driven development (“TDD”) as it’s traditionally introduced to beginners is officially off my list.
The problems with how TDD is typically introduced are fundamental, because they put the learner on a path that leads to a destination which might resemble where they want to go, but doesn’t actually show them the way to the promised destination itself. This sort of phenomenon happens often enough that I’ve decided to finally settle on a - WTF now, guys?
I think this illustration captures why arguments between developers over TDD tend to be unsatisfyingly dissonant. When a developer lodges a complaint like, “mock objects were everywhere and it was awful”, another developer operating from the context of the taller mountain might reply, “Huh? Mock objects are everywhere and it’s wonderful!” In fact, it’s typical for folks to talk over one another in debates about TDD, and I believe it’s because we use the same words and tools to describe and practice entirely unrelated activities. What’s a valid problem with TDD from the mountain on the left comes across as nonsense to someone scaling the mountain on the right.
