test-drivenlisted

# Test-driven development (XP-style) Tests define the specification. Design them from requirements before any implementation. The RED-GREEN-REFACTOR cycle is the heartbeat: write a failing test, make it pass with minimal code, then clean up while green. **Modern insight (2025)**: TDD + property-based testing pairing is the standard -- example tests prevent regressions, property tests discover edge cases. TDD also serves AI-assisted development: structural integrity keeps code understandable for both human and AI collaborators (Kent Beck, "Augmented Coding"). Mutation testing validates test quality beyond coverage metrics (TDD+Mutation: 63.3% vs TDD-alone: 39.4% mutation coverage). See [frameworks](references/frameworks.md) for language-specific test runners, property testing, coverage, and mutation tools. See [examples](references/examples.md) for brief TDD cycle patterns per language. --- ## When to Apply - New features with clear requirements (both inside-out and outside-in approaches valid) - Bug fixes -- write a failing test that proves the bug before fixing - Refactoring -- ensure coverage exists before restructuring - API contract enforcement -- test the interface, not internals - Property-based invariants -- complement example tests with PBT - Legacy code -- add characterization tests before modifying (Michael Feathers pattern) ## When NOT to Apply - Exploratory prototyping or spike research - One-off scripts, data migrations, generated code - Purely visual UI