Editorial note: I originally wrote this post for the TechTown blog. You can check out the original here, at their site. While you’re there, take a look around at their training courses.
Let’s get something out of the way right up front. You might have extensive experience with test driven development (TDD). You might even practice it routinely and wear the red-green-refactor cadence like a comfortable work glove. For all I know, you could be a bonafide TDD expert.
If any of that describes you, then you probably don’t actually misunderstand TDD. Not surprisingly, people that become adept with it, live, and breathe it tend to get it. But if that introductory paragraph doesn’t describe you, then you probably have some misconceptions.
I earn my living doing a combination of training and consulting. This affords me the opportunity to visit a lot of shops and talk to a lot of people. And during the course of these visits and talks, I’ve noticed an interesting phenomenon. Ask people why they choose not to use TDD, and you rarely hear a frank, “I haven’t learned how.”
Instead, you tend to hear dismissals of the practice. And these dismissals generally arise not from practiced familiarity, but from misunderstanding TDD. While I can’t discount the possibility, I can say that I’ve never personally witnessed someone demonstrate an expert understanding of the practice while also dismissing its value. Rather, they base the dismissal on misconception.
So if you’ve decided up-front that TDD isn’t for you, first be sure you’re not falling victim to one of these misunderstandings.