How do you practice red-green-refactor TDD in Java with JUnit 5, and how do parameterized tests (@ParameterizedTest) support data-driven test design?

## Test-Driven Development (TDD) **TDD** is a workflow where you write the *test before the production code*. It is language-neutral; here we run it through JUnit 5. The loop has three steps, often called the **red-green-refactor** cycle: 1. **Red** — Write one small test for a behavior that does **not exist yet**. Run it; it fails (or doesn't compile). The failure is the point: it proves the test can fail and defines exactly what "done" means. The bar is red. 2. **Green** — Write the **minimum** production code to make that test pass. It's fine to be crude (even hard-code a return) — the goal is a passing bar quickly, not elegance. The bar turns green. 3. **Refactor** — Now improve the design — rename, extract methods, remove duplication — **while keeping the test green**. Because the test passes throughout, the suite is your safety net: any regression turns the bar red instantly. Then repeat for the next tiny behavior. The benefits: code is **testable by construction** (you can't write untestable code if the test came first), the suite is **comprehensive** (every line exists to pass a test), and design pressure surfaces early (hard-to-test code reveals tight coupling). ### A red-green cycle in JUnit ```java // RED: write the test first; FizzBuzz doesn't exist yet -> fails @Test void threeIsFizz() { assertEquals("Fizz", FizzBuzz.of(3)); } // GREEN: simplest code that passes String of(int n) { return n % 3 == 0 ? "Fizz" : String.valueOf(n); } // REFACTOR: generalize once more tests force it (5 -> Buzz, 15 -> FizzBuzz) ``` A common refinement is the **"transformation priority"** idea: take the smallest step that generalizes the code, driven by adding the next failing test — you don't jump straight to the full algorithm. ## Why parameterized tests fit Many behaviors are really *one rule applied to many inputs*: boundary values, equivalence classes, a truth table. Writing a separate `@Test` per input is repetitive and obscures that they test the *same* logic. **`@ParameterizedTest`** runs one test method repeatedly, once per supplied argument set, each reported as its own case. You pair it with a **source** annotation that provides the data: ```java import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.*; @ParameterizedTest @ValueSource(ints = {2, 4, 100, -8}) // simple literals void evensAreEven(int n) { assertTrue(n % 2 == 0); } @ParameterizedTest @CsvSource({ "3, Fizz", "5, Buzz", "15, FizzBuzz", "7, 7" }) // rows of input,expected void fizzBuzzRules(int input, String expected) { assertEquals(expected, FizzBuzz.of(input)); } @ParameterizedTest @MethodSource("orderCases") // complex objects from a factory void totalsOrders(Order order, Money expected) { assertThat(order.total()).isEqualTo(expected); } static Stream<Arguments> orderCases() { return Stream.of( Arguments.of(new Order(...), Money.of(10)), Arguments.of(new Order(...), Money.of(0))); } ``` Source options: - **`@ValueSource`** — a single array of literals (ints, strings, etc.) bound to one parameter. - **`@CsvSource`** — inline comma-separated rows, each mapped to multiple parameters; great for input→expected tables. - **`@CsvFileSource`** — the same but read from a CSV resource file. - **`@EnumSource`** — one run per enum constant. - **`@MethodSource`** — a static method returning a `Stream<Arguments>` (or collection); the way to pass real objects. - **`@NullSource` / `@EmptySource`** — inject `null`/empty to test edge cases. **Test-design techniques this enables:** *equivalence partitioning* (one representative per class of input), *boundary value analysis* (test just-below/at/just-above limits), and *decision tables* — all expressed as data rows instead of duplicated methods. When one row fails, JUnit names that specific case, so diagnosis is fast. ## How TDD and parameterized tests combine In practice: TDD drives out the *core behavior* one small example at a time (red-green-refactor). Once the logic exists, you **promote** the accumulating examples into a single `@ParameterizedTest` table and add boundary/edge rows — getting broad coverage cheaply without inflating the number of test methods. The parameterized table also becomes living documentation of the rule. ## Mapping to the discipline Red-green-refactor and data-driven testing are universal practices; JUnit 5's `@ParameterizedTest` family is simply Java's mechanism for the data-driven part, and ordinary `@Test` + fast assertions are what make the TDD loop tight enough to be worthwhile.