test-driven-developmentlisted

# Test-Driven Development ## The Red-Green-Refactor Cycle ```text ┌─────────────────────────────────────────────┐ │ │ │ RED → write a failing test │ │ ↓ │ │ GREEN → write the minimum code to pass │ │ ↓ │ │ REFACTOR → clean up without breaking │ │ ↓ │ │ repeat ───────────────────────────────────┘ ``` **Red**: Write a test that describes one behavior you want. Run it. It must fail — if it passes without implementation, the test is not testing anything. **Green**: Write the simplest code that makes the test pass. Do not optimize. Do not add features. Just pass the test. **Refactor**: Clean up duplication, naming, and structure. Run the tests after every change. If any test breaks, the refactor changed behavior — that is a bug. The cycle is short. Each iteration should take minutes, not hours. If a cycle takes longer than 30 minutes, the behavior being tested is too large — split it. ## When to Apply TDD **Apply TDD for:** - New business logic with clear rules (validation, calculations, state machines) - Bug fixes — write a regression test that reproduces the bug first - Public service layer methods - API endpoints with defined acceptance criteria **Do not apply TDD for:** - Exploratory code where the design is not yet known — spike first, then write t