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.