Test-Driven Development (TDD) only makes sense if you’re well aware of what the outcome is going to be.

This is a common sentiment. I heard it again on social media. The person went on to explain:

In other word, if the applied algorithm, and its use case is something you’ve built in the past. TDD has absolutely no benefit when building something more sophisticated, requiring in-depth knowledge you don’t posses, e.g. while learning on the go.

So let’s wrestle with this idea a bit.

On the face of it, it makes intuitive sense, right? How can you write a test for code, if you don’t know what that code is supposed to do?

On the other hand, how can you write code if you don’t know what the code is supposed to do?

I’m sure we’ve all been there. We’re staring at a blank window in our IDE, and we have only a vague idea what our code should do, so we just start hacking. Eventually, some functionality starts to emerge.

Right. Doing TDD in that scenario would be pretty hard.

But here’s the thing…

That’s exactly when TDD, as an architectural design practice is most beneficial.

You see, by writing the test first, you force yourself to decide what the code should do before you start coding it. This is a good thing. It’s a feature of TDD, not a limiting factor.

If you don’t know what your code should be doing, you have no business writing any code anyway!