One of the first things you must learn when starting with test driven development - or TDD - is how to write a good, “red” test and how to make this test green.

And this is already harder than you might think.

A good red test constrains the implementation you are about to write in just the right way - not too little and not too much. It takes you one step closer to your overall design goal; that might still be pretty far away. It enables you to write an implementation that will allow you to make the next test red again.

To make the test green, you must write the smallest possible implementation that will pass the test. And most people I know were surprised - schocked! - how small is sometimes necessary.

Intro (TL;DR)

My name is David, and in this video series I am showing techniques and tricks and other interesting stuff around the general topic of software development.

By the way, if you liked this video, please subscribe and share it with your friends and followers - That would be awesome!

A good red test enables...

How do you get from “red” to “green”? You know TDD is “red-green-refactor”, and the “refactor” step is crucially important.

But when I teach it to developers and teams, I often see people people struggle much earlier. They do not know how to write the first test, how to get that test to green “correctly” and how to write the next test.

So in this video (and in some future ones) I want to talk about the basics you will need at the beginning of the TDD cycle.

Question / Problem

When I teach TDD trainings (or when I teach TDD as part of a larger training), I usually ask people to test-drive a “Hangman” game at the very beginning, before I explain anything but the basics.

All of them manage to write a red test and to write an implementation that makes this test green. But then they start to experience problems…

A good red test enables...

They write more tests, and all of those are green (but they do not mind because they do not know yet that this is a problem). Or they do not know how to write the next test.

Solution

What they must learn is take smaller steps. Sometimes comically small. And to still keep the overall goal in mind and take steps that take them closer.

This means: Think about the overall goal before you even write the first line of code. Have a rough list of things you are trying to achieve. Break this list down into even smaller items as you go.

In the hangman game, test the simplest possible start of the game in your first test. “Placeholder is a single ‘_’ when the word to guess is ‘a’”. Then write the simplest possible implementation: Return a single underscore.

@Test
public void placeholderIsSingleUnderscoreWhenWordToGuessIsA() {
    Hangman hangman = new Hangman("a");

    assertThat(hangman.hint()).isEqualTo("_");
}

//...

public class Hangman {
    public Hangman(String wordToGuess) {
    }

    public String hint() {
        return "_";
    }
}

Conclusion

In this video, I showed you how even getting started with the TDD cycle is hard and unintuitive for many developers. And how you must learn to take small - sometimes comically small - steps in TDD.

In some future videos, I want to get into some more detail about how to do this: Why to take small steps, Triangulation, the Specific/Generic Rule, and so on. And I also want to show you some code.

CTA

What was your biggest problem when you started with TDD? Or what keeps you from starting? What are your challenges nowadays? Tell me in the comments or shoot me a Tweet to @dtanzer.

And if you liked this video, please subscribe and share it with your friends and followers - That would be awesome!

Read / watch all parts of this series here: