Strategic TDD

The easy answer to the question “What is Test Driven Development? (TDD)” is “To write unit tests before the actual code”. But this is not the right answer. To better understand the real meaning of the TDD, let’s focus on the keyword “Driven”.

Letting the tests drive your development means that your code is designed by tests. And this approach obviously works in a iterative way.

Photo by

It starts with the red phase. We start writing a failing test, and then we write just the code needed to make that single test green. If you keep writing code following this simple rule, the tests really drive your code. In other words, tests let our design emerge.

To better understand the power of this procedure, just try to solve a simple kata by TDD. Then repeat the same kata but this time start with a different test. Your code will be quite different in the two katas.

TDD is a powerful tactics technique, it helps you “doing things” in the everyday work. But now a question arises…

Can we use TDD in a strategic way?

That is to say “Can we take deeper decisions with TDD?”. Before start reasoning about this topic, let’s focus for a moment on the meaning of the word test. Quoting Kent Beck in a recent interview

Tests are just one form of feedback, and there are some really good things about them

Ok, so let’s replace test with feedback and we obtain…

Feedback Driven Development

So what does it means to develop a software, driven by feedback, on a strategic level?

A first answer could be the Acceptance Test Driven Development (ATDD). In ATDD you write an acceptance test in advance of implementing the corresponding feature.You write this kind of tests collaborating with your client/product owner. So you’re just asking for a feedback on that feature without writing any line of code!

In my opinion ATDD could be not related to automated tests at all. You can also ask for an explanation of what you have to do to consider that thing done if it’s too expensive to build an automated end-to-end test. The important thing is the feedback itself and not the code. Also in this case the design of your entire project emerges from the feedbacks (AKA tests) like with standard TDD.

Can we go even higher with TDD?

Simply put, yes. Until now we talked about how to design a software from feedbacks (automated or not). But can we design an entire new product from feedbacks? Also a product that it’s no related to software at all?

When we talk about the design of a new product a corresponding approach of the TDD could be the Build–Measure–Learn loop from the Lean Startup methodology.

Photo by

Eric Ries, the creator of the Lean Startup methodology states that you should hit the market with a minimum viable product (MVP). The MVP it’s a version of your product that you should build with the least effort possibile with the purpose of asking feedbacks from the market. Then you use these feedbacks to learn what your potential users want and then you create a new version of your product. As you can see the design of your product emerge from the feedback, just like in the TDD.


For me TDD has never been about only the tests themselves. The real killer feature of TDD it’s to do only what it’s really important to complete a task. If we raise from the tactics level to a more strategic one, like with ATDD or Build–Measure–Learn, the feedbacks are even more important. In the end what I’ve learned from TDD, it’s that to build a software, a product or anything else, you need to rely on feedbacks, and automated ones are not always the best ones.

Like what you read? Give Francesco Strazzullo a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.