Test-Driven Development (TDD)

The problem: the test that is never written

The sales team of our shop wants a new rule: “Shipping costs 50,000 toman. But an order of 500,000 toman or more ships for free.”

The usual way is this:

1. We write all the code at once. Sometimes with a few extra cases that “may be needed later”.
2. We try it by hand. It works. We are happy.
3. We say we will write the test later. But the next task arrives and the test is never written.
4. Even if we write it, it is hard. Because the class was not designed to be tested from the start. For example, it is connected directly to the database or the system clock.

The TDD idea: test first, then code

In Test-Driven Development (Test-Driven Development) we reverse the order. We write no line of main code, except to make a red test green. The work happens in a short, repeated cycle:

1. Red (Red). Write a small test for one new behavior. Run it and see that it fails. If it is green, either the behavior already existed or the test is wrong.
2. Green (Green). Write the simplest code that makes the test green. In this step, beautiful code does not matter. Only getting green matters.
3. Refactor (Refactor). Now that all tests are green, clean up the code. Improve the names and remove repetition. After each small change, run the tests.

Live example

Build the shipping cost rule step by step with TDD. Watch the color of each step and the change in the code:

Look at step two. The code “always return 50,000” looks strange. But this is on purpose, for two reasons:

1. The step stays small. If something breaks, we know exactly which change broke it.
2. The next test forces the code to become general. Kent Beck (Kent Beck) calls this Triangulation. It means we push the code toward the general rule with two or more examples.

If the solution is fully clear from the start, you do not need to take these very small steps. You can write the right code directly. But when you are not sure, make the steps smaller.

The final code

After a few rounds, the tests and the code look like this:

public class ShippingCostTests
{
    [Theory]
    [InlineData(200_000, false, 50_000)]
    [InlineData(499_999, false, 50_000)]
    [InlineData(500_000, false, 0)]
    [InlineData(200_000, true, 0)]
    public void Shipping_cost_follows_the_rules(int total, bool isVip, int expected)
    {
        var cost = ShippingCost.For(total, isVip);

        Assert.Equal(expected, cost);
    }
}

public static class ShippingCost
{
    private const decimal FreeFrom = 500_000m;
    private const decimal Standard = 50_000m;

    public static decimal For(decimal orderTotal, bool isVip) =>
        isVip || orderTotal >= FreeFrom ? 0m : Standard;
}

Look at the two rows 499,999 and 500,000. These are the edges of the rule. Writing the test before the code forces us to think about these edges and ask the sales team: “Is exactly 500,000 free, or only above it?”

Why does TDD help?

1. Better design. When you write the test first, you first look at the class from the view of its user. A class that is hard to test usually has a bad design. You find this out very early.
2. Only the needed code. Every line of code was written because of a test. Less extra code “for a rainy day” gets written.
3. A safety net. Every behavior has a test. So the next refactoring is not scary.
4. Living documentation. The test names explain the business rules and always match the code.
5. Small steps. You are always only a few minutes away from a healthy state. If you get lost, you undo the last change.

Two styles: inside-out, outside-in

Important rules

1. Only one red test at a time. Several red tests together mean the step is too big.
2. Do not skip the refactor step. Without it, TDD only produces messy code with tests.
3. Do not write extra code in the green step. If you think of a new behavior, write it in a list. Come back to it later with a new test.
4. Test the behavior, not the implementation. Otherwise the refactor step breaks the tests, and TDD becomes painful.
5. Tests must be fast. A TDD cycle is a few minutes. If running the tests takes a minute, the cycle is lost.

Common mistakes

When to use TDD?