test-driven-development

Test-Driven Development

Navigation hub for applying TDD in day-to-day implementation work.

When to Use

• "Write tests first for this feature."
• "How should I do red-green-refactor here?"
• "I need to reproduce a bug with a failing test first."
• "I want to refactor safely while preserving behavior."

When Not to Use

• End-to-end scenario design across full systems.
• Performance benchmarking and load testing.
• Security testing workflows.

Scope

In Scope

• Unit test design and behavior-driven assertions.
• Red-Green-Refactor cycle execution.
• Mock/stub isolation strategy.
• Naming and organization conventions for maintainable tests.

Out of Scope

• Full E2E harness setup and browser automation pipelines.
• Infra-only test framework bootstrapping.
• Non-deterministic perf profiling.

Workflow

1. Write the smallest failing test that expresses one behavior.
2. Run tests and verify failure is for the expected reason.
3. Implement minimal code to make the test pass.
4. Refactor while keeping the suite green.
5. Repeat for next behavior/edge case.

Example: Red-Green-Refactor Cycle (TypeScript)

RED — write the failing test first:

// add.test.ts
import { add } from "./add";

test("add returns the sum of two numbers", () => {
  expect(add(2, 3)).toBe(5);
});
// ❌ Fails: cannot find module './add'

GREEN — implement the minimum code to pass:

// add.ts
export function add(a: number, b: number): number {
  return a + b;
}
// ✅ Test passes

REFACTOR — improve without breaking green:

// add.ts — no logic change needed here, but you might rename,
// extract constants, or improve types while the suite stays green.
export const add = (a: number, b: number): number => a + b;
// ✅ Still green

Example: Elixir variant

# test/math_test.exs  (RED)
test "add/2 returns the sum" do
  assert Math.add(2, 3) == 5
end

# lib/math.ex  (GREEN)
defmodule Math do
  def add(a, b), do: a + b
end