When do you TDD?

I get asked this question regularly, and my answer is usually “I TDD whenever I can.” That means I don’t always TDD, and not only that, sometimes TDD means Test Driven Development, and other times it means Test Driven Design.

Here’s my ordered list, from least-TDD-ish to most-TDD-ish, of things I do that I consider to be both programming and productive:

  1. Whether planning or problem solving, I often stare at the wall. Some of my best problem solving time is all in my head. For big problems to solve, I often dream about code. If I didn’t like to code, if I didn’t like the job, I’m not sure it would be like this.

  2. Sometimes the domain of the problem is well known, or the outputs of a process, or the API I’m integrating with is already specified. In that case I’ll lay out those data points all at once when I am starting, and then add tests.

  3. If I know where I need to end up, but I’m not sure what’s going to work, I’ll code it as a Spike. If that code is sloppy, or unclear, or otherwise doesn’t look right, that’s when I should delete it and start over with TDD. It seems crazy, but the code you write that second time is almost always better.

  4. If I write a Spike that seems like otherwise reasonable and clean code, I’ll go back and fill in the tests. Perfect, polished code is not my goal. I like code like that, more importantly I like to write code like that, but it is rarely time or cost effective. Reasonable and clean code isn’t just readable and understandable, it’s code that you see how to evolve into something better. It should be code that is easy to replace or delete.

  5. If I am adding a new feature, the very regular activity of “hey can you add this simple new thing to the thing we’ve already got?” kind of change, I will TDD it. Adding a new field can easily involve changes to bunch of different files that operate at different levels of the stack, and I don’t want to break anything as I go. I also want to hold onto the very important idea that when I intend to write a breaking test, I expect it to be red, and sometimes it is green. Sometimes it’s green and it takes me a while to resolve why that’s happening, because it is not always a simple thing.

  6. What I don’t do is try to plan ahead in a way that is like Waterfall. The phrase Big Up-Front Design is always used with a negative connotation, and to me, it always feels like a committment to dishonesty. I know that once programming starts, my understanding will change, and I will need a better plan.

  7. In a team environment, I practice small design all the time. If I can express the important parts of a new feature or a change as a set of acceptance tests, then I can write user stories that make sense. I try not to write user stories for changes that do not impact users. I will rewrite acceptance tests and user stories to clarify the problem I’m solving while I’m solving it.

  8. If I am trying to find a bug, I will use a combination of a REPL and tests until I can reproduce it. Almost every bug should have a test to prove you’ve fixed it. In my head, I call this Test Driven Debugging.

  9. If my goal, my change at hand, is something I can verbalize in English, I will start with tests. It might take me a while to get to the point where I understand what I’m doing well enough such that the next little change I need to make is something I can write in English first. It might even take a rubric of other activities for me to reach this zone of productivity. Red, green, refactor is where I write the best code.

When I am programming:

TDD, whatever the flavor of it is you’re practicing, is a tool like any other. If you don’t understand it, if you aren’t comfortable really doing it, then you can’t afford to skip it. If you aren’t sure you know it, show me your code, or better yet, let’s pair!