Everyone does Test Driven Development wrong
Everyone does Test Driven Development wrong
How many tests do you write at one time? Just about everyone gets this wrong, especially if you're in the "TDD doesn't work" camp.
Now and then I have this recurring, frustrating conversation. It’s centered on the idea that Test Driven Development (TDD) doesn’t work or doesn’t bring value. It’s frustrating because I disagree and I have the empirical evidence to prove it. It’s also frustrating because everyone I have this conversation with is emotionally committed to being right, and typically unwilling to reconsider their choices.
It’s not surprising. TDD has been around for close to 25 years, which I think is long enough for a tool or technique to prove itself. And there’s ample evidence — just about all of it pointing very firmly at improved outcomes. The only true “zero defect” projects I’ve worked on have followed a form of TDD. In contrast, most of the projects I’ve experienced that don’t follow TDD tend to ship a lot more defects.1
I guess my point is, if you’re still opposed to TDD, you aren’t interested in considering the alternatives.
But here’s the thing — just about every time I have this conversation it’s clear to me the person I’m sharing it with has fundamental misconceptions about TDD. For example, the biggest one is that you have to write all the tests up front. Not just define them, but code them. Which is horrible. And all wrong, and I totally agree that if that was TDD then it would suck and you shouldn’t do it! But it’s not.
Which is why I was delighted to see
’s recent article on Cannon TDD. He very succinctly describes the process in a quick read. But then I was even more excited to see add this diagram which makes it even clearer and easier to follow:
Personally, I love bringing it up a notch with Behavior Driven Development (BDD). Essentially the same thing, but BDD describes behavior, rather than a unit-level functional test. I think BDD gives you a great edge because it keeps you focused on what your customer wants, in terms your customer understands. That helps protect your value stream.
For completeness, here’s the definitive and correct approach to TDD (but you can get this from Kent’s article, too):
Write a list of the test scenarios you want to cover.
Turn exactly one item on the list into an actual, concrete, runnable test.
Change the code to make the test and all previous tests pass (adding items to the list as you discover them).
Optionally refactor to improve the implementation.
Until the list is empty, go back to step #2.
Taken in this style, “it just works.”
Kent Beck, Test Driven Development: By Example 1st Edition (November 8, 2002), Addison-Wesley Professional. ISBN-13: 978-0321146533.