Test-Driven Development

By the end of this lesson you'll be able to drive your code with tests instead of writing them afterwards — working the Red-Green-Refactor cycle in tiny, safe steps, using failing tests to shape clean designs, and knowing the few places where TDD costs more than it pays.

1. Red → Green → Refactor (the worked cycle)

Here's the whole cycle in one go, in xUnit. You start in Red: a test for RomanConverter that won't even compile because the class doesn't exist yet. Then Green: the smallest converter that passes all four tests. Then Refactor: tidy the code while the tests stay green. Read every comment, then picture running dotnet test and watching the bar flip from red to green.

using Xunit;

// === The TDD cycle: RED -> GREEN -> REFACTOR ===
// Goal: a Roman-numeral converter. We grow it one failing test at a time.

public class RomanNumeralTests
{
    // ── STEP 1: RED ───────────────────────────────────────────────
    // Write ONE failing test BEFORE any production code exists.
    // Run it now and it FAILS to even compile — RomanConverter is missing.
    [Fact]
    public void One_Returns_I()
    {
        var converter = new RomanConverter();
        Assert.Equal
...

Note: this example uses the xUnit framework, so it runs with dotnet test in a test project rather than in the simple online editor. The "Try it Yourself" exercises below are plain C# you can paste and run anywhere.

2. Baby Steps & Triangulation

Baby steps means you only ever write enough code to pass the current test — sometimes that's literally return 0;. That looks like cheating, but it's deliberate: it keeps you in a known-good state and stops you building features nobody has asked for yet. Triangulation is how you escape a fake answer: you add a second test with a different input, and now the hard-coded value fails, forcing real logic to emerge. Two points define a line; two tests define the behaviour.

using Xunit;

// === Baby steps & triangulation, frame by frame ===
// Each test pushes the code to do a LITTLE more. You never write a
// feature you don't yet have a failing test demanding.

public class SumTests
{
    // RED #1 — the simplest case. Empty input.
    [Fact]
    public void Empty_Returns_Zero()
    {
        Assert.Equal(0, Calculator.Sum(new int[] { }));
    }

    // GREEN #1: 'return 0;' literally passes. That feels like cheating —
    // it's not. A second test (triangulatio
...

3. Your Turn: Make the Failing Test Pass

Now you drive the cycle. The program below already contains a failing test (Red) for IsLeapYear — the assertions are written, but the method body is empty, so they'd print FAIL. Don't touch the test: fill in the one blank in the method to turn every line green (PASS). This is plain C# with a tiny built-in assert helper, so you can run it in any compiler.

using System;

class Program
{
    // 🎯 YOUR TURN (RED -> GREEN) — a failing test is already written below.
    // The test calls IsLeapYear(...) and the assertions currently FAIL because
    // the method body is empty. Your job: fill in the body to make them PASS.

    // RED: this test is given. Do NOT change it — make the code satisfy it.
    static void Test_IsLeapYear()
    {
        Assert(IsLeapYear(2024) == true,  "2024 is a leap year");   // /4
        Assert(IsLeapYear(2023) == false
...

4. Your Turn: Write the Next Test First

Real TDD is a loop, so here you add the next failing test yourself before extending the code. Fizz(n) already handles multiples of 3. Your job: add a new assertion that 5 should return "Buzz" (it fails now — that's Red), then add the one line to Fizz that makes it pass (Green). Fill in both blanks.

using System;

class Program
{
    // 🎯 YOUR TURN (write the next test) — Fizz works; now drive "Buzz".
    // The cycle: add a failing test FIRST, watch it fail, then extend Fizz()
    // just enough to make it pass.

    static void Test_Fizz()
    {
        Assert(Fizz(1) == "1",    "1 stays \"1\"");
        Assert(Fizz(3) == "Fizz", "3 is divisible by 3 -> Fizz");
        Assert(Fizz(6) == "Fizz", "6 is divisible by 3 -> Fizz");

        // 1) Add YOUR new failing test here: 5 should return
...

5. Refactoring Under a Green Bar

The third step is the one beginners skip — and it's where TDD pays off. Once your tests are green, they pin the behaviour in place. That means you can rewrite a tangled implementation into a clean one and instantly know whether you broke anything: if the bar stays green, you didn't. Refactoring without tests is a leap of faith; refactoring under green is routine.

using Xunit;
using System.Linq;

// === Refactoring under a green bar ===
// The tests pin the BEHAVIOUR. So you can rip out the messy implementation
// and replace it with a clean one — if the bar stays green, you didn't
// break anything. That safety net is the whole point of TDD.

public class DiscountTests
{
    [Theory]
    [InlineData(0,   0.00)]    // no items -> no discount
    [InlineData(1,   0.00)]    // 1 item   -> 0%
    [InlineData(5,   5.00)]    // 5 items  -> 5% of 100
    [Inlin
...

// ❌ Brittle — asserts an internal detail
Assert.Equal(2, cart.InternalItemArray.Length);

// ✅ Robust — asserts observable behaviour
Assert.Equal(19.98m, cart.Total);

using System;

class Program
{
    // 🎯 MINI-CHALLENGE: TDD the classic FizzBuzz(n)
    // The tests are GIVEN (this is RED). Implement FizzBuzz so every line
    // prints PASS — and do it in baby steps: make ONE assertion pass, then
    // the next, refactoring as you go.
    //
    // Rules:
    //   • divisible by 3 AND 5 -> "FizzBuzz"   (check this FIRST!)
    //   • divisible by 3       -> "Fizz"
    //   • divisible by 5       -> "Buzz"
    //   • otherwise            -> the number as te
...