Three Modes of TDD

Among the discomfort of being sick over the weekend, I also had the pleasure to do some reading – Kent Beck’s TDD by Example in this case[^1]. This inspired me to write something about TDD – a topic that polarizes people a lot. Reading different opinions about TDD, I found that most TDD opponents don’t know what it really means and haven’t even partially mastered it. Here’s my first attempt to stop this trend a little bit.

One thing that’s nice about TDD is that it lets you to make progress, even if you don’t have the final solution in your mind right away. Depending on your knowledge of the problem, possible solutions and their implementations, you can chose one of three modes to move forward. We’ll take a closer look at this, using an oversimplified example of calculating square’s area.

Obvious Implementation

Given you know the problem, possible solutions and their implementations very well, there’s no point in messing around with stupid tricks or games. The example of square’s area shows that very well.

You start with a test that describes the problem:

Then you write the obvious implementation:

Bam, done! Things work so well when the problem is simple enough (that’s why I chose this one). But let’s assume that you don’t know how to code it up right away. What then?

Fake It, ‘Til You Make It

Given you know the problem and solutions, but the way you code them up is not immediately obvious to you, you can use a trick called Fake it, ’til you make it. Given the same test as above, you could start your implementation like this:

See? You’re “faking” that the class works just to make the test pass. The next thing to do is to realize Why does this constant satisfy the requirements of the test?. Relax, let the magic flow through your body straight to your brain. Oh yes, it’s the square of 3! Code it up:

Now, you’re still faking, but you’re closer to the final solution. You gather brain power that exceeds it’s capacity, your head starts electrizing, your hair looks like on memes with Albert Einstein and you got it! It couldn’t be more obvious! You just need to replace the constants with the edge. Here you go again:

Great! But what if you don’t even know the solution?! How do you make progress in this case?


This is heavy magic. At this point, TDD opponents on DZone are no longer reading, they’re already writing angry comments about how stupid this article is. But we don’t stop. We want power, more power! To unleash the power of triangulation, we have to get back to the roots. What’s the most dumb example of a square? A square with edge of 0![^2]

With triangulation, we’ll be doing similar steps as in Fake it ’til you make it. We’ll start by hardcoding the result.

In this case, we assume that we don’t know yet the final answer, so we can’t generalize based on this constant. Instead, we’ll provide another test that leads us closer to the final solution – the next most dumb square:

Now the old solution obviously fails. We have to do something to make it work for both cases. Edge of 0, means area of 0, while edge of 1 means area of 1. What could it be? No. This can’t be true. Are you saying that area is equal to the edge?! Well, for now it is.

It works. Let’s keep going. Edge of 2!

Holy moly, it broke again! What do you do? You think, take a walk, get a shower, drive a car, meditate and finally…

You got it! Step by step. From nothing to 0.0. From 0.0 to edge. From edge to edge * edge. It wasn’t that hard. Congratulations!


In reality you won’t be solving such simple problems, but the principles remain. If you know the solution and it’s implementation right away, just code it up – it’s the obvious implementation way. If you know the solution, but coding it up appears complicated – fake it ’til you make it. Also, go for fake it ’til you make it, when things unexpectedly mess up (aka your tests fail). This often happens when you have algorithms with indexes or lot’s of nested calculations. It’s no shame to slow down and do it step by step instead of trying MAX_INT combinations of indexes or brackets. Finally, if you don’t know the solution and you’re exploring, try triangulation. Go step by step, from the simplest cases to the most complicated ones. From very specific, stupid implementation, to the one that solves all your requirements.

[^1]: And The Skull Throne, but I’ll save this one for another post. [^2]: I’m not even sure if that’s a valid square, but for the sake of example, please assume so!

About the Author Grzegorz Ziemoński

King of Tidy Java, nerd that thinks about producing perfect software all the time and proud owner of 2 cats.

follow me on:
  • Josep Prat

    Why do you need to fake it? Wouldn’t be enough to just leave the tests failing?

    • The whole point of those modes is like this: you’ve written a failing test and now you have to make it pass. If you know what the solution is, you just code it up. But if you don’t know, techniques like Fake it til you make it or Triangulation can help. I was focused on having some fun when writing the text, maybe I didn’t express this well enough. What do you think?

      • Josep Prat

        I guess I use the “fake it” but unconsciously; it consist of writing as many tests as I can for this unknown algorithm and then write a naive algorithm and then iterate over it until all my tests are green.

        • That sounds more or less like “fake it”. I usually try not to write more than one failing test, because I want to “get to green ASAP”, but your approach seems intersting. Looks like instead of “getting to green”, you’re “getting more green” with each step. I’ll definitely give it a try.

  • it_madness

    Good luck trying to triangulate more complex problems… I think that is a really bad idea.

    Imagine for example that you have to solve a pretty complex math problem and you don’t know the algorithm. Then you also don’t have enough knowledge to define the correct tests. (So Joseps method to ‘write as many tests as he can’ also won’t work. And good luck trying to triangulate that stuff.

    You really have to know the correct algorithm. Just an example: Linear systems of equations.
    (Of course there are libraries out there…)

    That criticism of course doesn’t touch TDD, just your approach is wrong.