Test-Driven Development done right

Photo by Glenn Carstens-Peters on Unsplash

During the last months that I’ve been working with Accenture, I saw some talks about testing in general and Test Driven Development. While talking to some colleagues, I got the impression that everyone writes tests, what’s awesome, but everyone has a slightly different approach to doing it. Some presenters said they do TDD, and I strongly disagreed. People write tests, and I highly value that, so keep doing it!

I’m going to show my understanding and my way of doing TDD. If you prefer to stick with another approach, that’s fine. But from experience, I’ll always suggest trying my way 😜

What is Test-Driven Development?

Let’s try finding common ground first. Test-Driven means that my implementation of the code is based on a test suite, agree? Why not simply take our acceptance criteria and write tests for all those criteria before we implement anything? This way, we know at the end that the story is complete.

This is not TDD, in my opinion. TDD is not about fulfilling the criteria of a user story. What if there is no user story, because for whatever reason? Don’t you want to write tests then? Also, you’d end up with a failing build for hours, or even days, if you go this way 😭.
Maybe, it’s important to know the intention behind TDD if it’s not to fulfill acceptance criteria.