test-driven-development

name	test-driven-development
description	Use when implementing any feature or bugfix, before writing implementation code

Test-Driven Development (TDD)

Overview

Write the test first. Watch it fail. Write minimal code to pass.

Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.

The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Red-Green-Refactor

RED - Write Failing Test

Write one minimal test showing what should happen. One behavior, clear name, real code.

Verify RED - Watch It Fail

MANDATORY. Test must fail for expected reason (feature missing, not typos).

GREEN - Minimal Code

Write simplest code to pass the test. Don't add features beyond the test.

Verify GREEN - Watch It Pass

MANDATORY. Test passes, other tests still pass, output pristine.

REFACTOR - Clean Up

After green only. Remove duplication, improve names, extract helpers. Keep tests green.

Good Tests

• Minimal: One thing per test
• Clear: Name describes behavior
• Shows intent: Demonstrates desired API

Common Rationalizations

• "Too simple to test" - Simple code breaks. Test takes 30 seconds.
• "I'll test after" - Tests passing immediately prove nothing.
• "Already manually tested" - Ad-hoc ≠ systematic.
• "Deleting X hours is wasteful" - Sunk cost fallacy.

Red Flags - STOP and Start Over

Code before test, test passes immediately, "just this once", "keep as reference".

Example: Bug Fix

RED: Write test for empty email rejection. Verify RED: Test fails with expected message. GREEN: Add validation check. Verify GREEN: Test passes. REFACTOR: Extract validation if needed.