Understanding Test‑Driven Development (TDD), UTDD, ATDD, and BDD with a Practical Java Example

In modern agile development, Test‑Driven Development (TDD) promotes writing tests before code, ensuring requirements are covered and enabling safe refactoring. The article clarifies that TDD is a mindset rather than a silver bullet, and that the "T" can represent any type of test.

It addresses the recurring claim that "TDD is dead," explaining that the misconception stems from a narrow view of TDD as merely unit testing with mocks, ignoring broader testing strategies.

The piece distinguishes three related methodologies:

TDD : focuses on unit tests written first (red‑green‑refactor cycle).

UTDD (Unit Test‑Driven Development): the "mother" level, handling code‑level tests.

ATDD (Acceptance Test‑Driven Development): the "father" level, defining business‑level acceptance criteria before implementation.

BDD (Behavior‑Driven Development): builds on TDD/ATDD, using natural language to describe expected behavior, fostering collaboration among developers, testers, and product owners.

A comparison table highlights definitions, participants, and primary focus for TDD, BDD, and ATDD.

The article then provides a concrete Java case study: a "StrangeCalculator" with three boundary conditions (input > 0, = 0, < 0). It walks through the classic TDD cycle:

public class StrangeCalculatorTest {
    private StrangeCalculator strangeCalculator;

    @BeforeEach
    public void setup() { strangeCalculator = new StrangeCalculator(); }

    @Test @DisplayName("input > 0 returns input‑1")
    public void givenGreaterThan0() {
        int input = 1, expected = 0;
        int result = strangeCalculator.calculate(input);
        Assertions.assertEquals(expected, result);
    }

    @Test @DisplayName("input < 0 returns input+1")
    public void givenLessThan0() {
        int input = -1, expected = 0;
        int result = strangeCalculator.calculate(input);
        Assertions.assertEquals(expected, result);
    }

    @Test @DisplayName("input == 0 returns 0")
    public void givenEquals0() {
        int input = 0, expected = 0;
        int result = strangeCalculator.calculate(input);
        Assertions.assertEquals(expected, result);
    }
}

Initially the StrangeCalculator class throws UnsupportedOperationException to make tests fail (red phase). The implementation then evolves step‑by‑step, first handling the >0 case, then <0, and finally =0, turning the tests green.

public class StrangeCalculator {
    public int calculate(int input) {
        if (input > 0) return input - 1;
        else if (input < 0) return input + 1;
        else return 0;
    }
}

After all tests pass, the article suggests refactoring by extracting private helper methods for each branch, demonstrating clean code practices.

public class StrangeCalculator {
    public int calculate(int input) {
        if (input > 0) return doGivenGreaterThan0(input);
        else if (input < 0) return doGivenLessThan0(input);
        else return doGivenEquals0(input);
    }
    private int doGivenGreaterThan0(int i) { return i - 1; }
    private int doGivenLessThan0(int i) { return i + 1; }
    private int doGivenEquals0(int i) { return 0; }
}

The article also recommends tooling for UTDD in Java: JUnit for test execution, AssertJ for fluent assertions, and Mockito for mocking, and mentions using JaCoCo to verify test coverage.

Overall, the guide provides a comprehensive overview of test‑first development philosophies, their differences, practical implementation steps, and best‑practice tooling.