Test-Driven Development

Changing code without tests is like performing surgery in the dark. You know something hurts, but you cannot see what you are touching, and every cut might make it worse. Over time this fear calcifies into paralysis: nobody dares refactor the messy function, so the mess grows, and the codebase slowly rots from the inside.

Test-Driven Development is a discipline that flips the order. Instead of writing code and hoping it works, you write a test first — watch it fail — then write exactly enough code to make it pass. The test is not an afterthought; it is the specification. When every feature starts life as a failing test, you build a safety net one strand at a time, and the fear of change evaporates. You stop praying your code works and start proving it.

flowchart LR
  R["Red<br/>write a failing test"] --> G["Green<br/>write minimum code"]
  G --> F["Refactor<br/>clean up"]
  F --> R
  style R fill:#b91c1c,color:#fff
  style G fill:#1e7f3d,color:#fff
  style F fill:#3776ab,color:#fff

The TDD loop: Red-Green-Refactor, repeated for every small behavior.

The TDD cycle: Red, Green, Refactor

TDD moves in a tight loop of three steps.

Red — write a single test that describes one small behavior you want. Run it and watch it fail. This proves the test is actually checking something, and it gives you a clear error message to drive the next step.
Green — write the smallest amount of code that makes that test pass. Do not worry about elegance; duplication and shortcuts are allowed here. The goal is working code, not beautiful code.
Refactor — clean up the mess you just made. Rename variables, remove duplication, improve structure. The tests stay green the whole time, so you know you have not broken anything.

Each loop takes seconds or minutes, not hours. The result is code that is tested by definition, because the test existed before the code it exercises.

The end state after a TDD loop: tests written first, then the function that satisfies them.

function assertEqual(actual, expected) {
  if (actual !== expected) {
    throw new Error(`Expected ${expected}, got ${actual}`);
  }
}

function double(n) {
  return n * 2;
}

assertEqual(double(3), 6);
assertEqual(double(0), 0);
assertEqual(double(-2), -4);
console.log("all green");

Why red matters

A test that passes before you write the code is worse than useless — it is a lie. It gives you a green checkmark while the function underneath might be empty, misspelled, or completely wrong. The red step is your proof that the test is wired correctly and will actually catch the bug it claims to catch.

This is why TDD insists you run the test immediately after writing it, before the function exists. You should see the exact failure you expect: a ReferenceError because the function is missing, or an assertion mismatch because the stub returns undefined. If you see a pass, investigate — you may have tested the wrong function, or the assertion might be checking != instead of ===.

flowchart TD
  A["Big-bang coding"] --> B["write everything"] --> C["test at the end"] --> D["many bugs at once"]
  E["TDD"] --> F["write one test"] --> G["write minimum code"] --> H["refactor"] --> F
  style D fill:#b91c1c,color:#fff
  style H fill:#1e7f3d,color:#fff

Big-bang coding piles bugs at the end; TDD discovers them one at a time while they are still cheap.

A more complex unit tested for happy path and edge cases.

function assertEqual(actual, expected) {
  if (actual !== expected) {
    throw new Error(`Expected ${expected}, got ${actual}`);
  }
}

function absolute(n) {
  return n < 0 ? -n : n;
}

assertEqual(absolute(5), 5);
assertEqual(absolute(-3), 3);
assertEqual(absolute(0), 0);
console.log("absolute tests pass");

The minimum-code discipline

The hardest habit in TDD is stopping. Once the test is red, your fingers itch to write the full solution — handle every edge case, add validation, optimize for performance. Resist. The green phase is deliberately narrow: write the simplest code that turns the light from red to green.

Why? Because small steps mean small mistakes. If you write twenty lines and the test still fails, you have twenty lines to debug. If you write two lines and the test passes, you know exactly what worked. The edge cases and polish come later, each with its own test. TDD is not lazy; it is incremental.

flowchart LR
  A["messy code<br/>that passes"] --> B["refactor"]
  B --> C["clean code<br/>that still passes"]
  B -->|tests red| D["undo last change"]
  style C fill:#1e7f3d,color:#fff
  style D fill:#e0900b,color:#fff

Refactoring transforms messy code into clean code while the test harness keeps behavior locked.

Refactor with confidence

Refactoring without tests is renaming variables and hoping. Refactoring with tests is mechanical: you change the shape of the code while the behavior stays locked in place by your assertions. If a test turns red, you undo the last change and try again. There is no need to manually retest every path through the program; the suite does that for you in seconds.

This is where TDD pays for itself. The time you spent writing tests upfront is repaid tenfold when you later need to swap an algorithm, split a function, or redesign a data structure. The tests are a harness that lets you pull the code apart and reassemble it without dropping pieces. Teams that practice TDD move faster over the long term because they are not afraid of their own code.

Refactored for clarity: the behavior is identical, but the tests prove nothing broke.

function assertEqual(actual, expected) {
  if (actual !== expected) {
    throw new Error(`Expected ${expected}, got ${actual}`);
  }
}

function greet(name) {
  const target = name || "stranger";
  return `Hello, ${target}`;
}

assertEqual(greet("Ada"), "Hello, Ada");
assertEqual(greet(""), "Hello, stranger");
assertEqual(greet("Z"), "Hello, Z");
console.log("refactored tests pass");

Exercise

What does this print? The assertions pass, so track which branch of the try/catch executes.

function assertEqual(a, e) {
  if (a !== e) throw new Error("fail");
}
function add(a, b) {
  return a + b;
}
const out = [];
try {
  assertEqual(add(2, 2), 4);
  out.push("A");
  assertEqual(add(0, 0), 0);
  out.push("B");
} catch (e) {
  out.push("C");
}
console.log(out.join(","));

Your prediction — what does this print?

Exercise

Write capitalize(s) that returns the string with its first character uppercase and the rest lowercase. Return an empty string if s is empty. Also write assertEqual(actual, expected) with strict equality, and three assertions that cover: a normal lowercase word, an all-uppercase word, and a single letter.

function capitalize(s) {
  // return capitalized string
}

function assertEqual(actual, expected) {
  // strict equality assertion
}

// write your assertions below

function capitalize(s) {
  if (s.length === 0) {
    return "";
  }
  return s[0].toUpperCase() + s.slice(1).toLowerCase();
}

function assertEqual(actual, expected) {
  if (actual !== expected) {
    throw new Error(`Expected ${expected}, got ${actual}`);
  }
}

assertEqual(capitalize("hello"), "Hello");
assertEqual(capitalize("WORLD"), "World");
assertEqual(capitalize("a"), "A");

Exercise

This percent(value, total) was written without tests and returns NaN when total is 0. Fix the function so the third assertion passes as well, without changing the tests.

function percent(value, total) {
  return (value / total) * 100;
}

function assertEqual(actual, expected) {
  if (actual !== expected) {
    throw new Error(`Expected ${expected}, got ${actual}`);
  }
}

assertEqual(percent(50, 100), 50);
assertEqual(percent(0, 80), 0);
assertEqual(percent(25, 0), 0);

function percent(value, total) {
  if (total === 0) {
    return 0;
  }
  return (value / total) * 100;
}

function assertEqual(actual, expected) {
  if (actual !== expected) {
    throw new Error(`Expected ${expected}, got ${actual}`);
  }
}

assertEqual(percent(50, 100), 50);
assertEqual(percent(0, 80), 0);
assertEqual(percent(25, 0), 0);

Exercise

What does this print? Track the array out through each passing assertion.

function assertEqual(a, e) {
  if (a !== e) throw new Error("fail");
}
function sumPositive(arr) {
  let total = 0;
  for (const n of arr) {
    if (n > 0) total += n;
  }
  return total;
}
const out = [];
try {
  assertEqual(sumPositive([1, -2, 3]), 4);
  out.push("A");
  assertEqual(sumPositive([]), 0);
  out.push("B");
  assertEqual(sumPositive([-1, -2]), 0);
  out.push("C");
} catch (e) {
  out.push("D");
}
console.log(out.join(","));

Your prediction — what does this print?

Exercise

In TDD, you have just written a test for calculateDiscount(price) and it fails because the function does not exist yet. What is the NEXT correct step?

Recap

TDD is Red-Green-Refactor: write a failing test, make it pass with minimal code, then clean up safely.
The red step proves your test is real; never trust a test you have not seen fail.
The green step rewards restraint: the smallest change that passes keeps debugging small and feedback immediate.
Refactoring with a green suite lets you improve design without breaking behavior.
Tests written first become executable specifications that document intent and catch regressions.
TDD does not eliminate bugs, but it finds them seconds after they are born, when they are cheapest to fix.
The discipline feels slow at first, but it accelerates dramatically as the codebase grows.

The TDD cycle: Red, Green, Refactor

Why red matters

The minimum-code discipline

Refactor with confidence

Recap

Checkpoint quiz

Go deeper — technical resources