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 an iterative way.
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 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 if we replace test with feedback, we obtain…
Feedback Driven Development
What does it means to develop 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 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 software from feedbacks (automated or not). But can we design an entirely new product from feedbacks? Also, a product that it’s not 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.
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 possible 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.
Conclusion
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 feedback, and automated ones are not always the best ones.
If you liked this post, you can buy me a virtual coffee ️😊
