# TDD — Red-Green-Refactor

## Rules
1. Never implement without failing test first — proves requirement exists.
2. One test at a time — isolates failures to single behavior.
3. Run tests every phase — execution is proof, assumptions aren't.
4. Minimum code to pass — over-engineering makes refactoring harder.
5. Test fails → fix code, not test — changing tests hides bugs.
6. Refactor = structure only — behavioral changes without test updates create silent regressions.
7. Report each phase: Red (test+failure) → Green (change+pass) → Refactor (improvement+pass)

## Anti-Patterns
- Test + implementation same step — can't verify test detects failure.
- Tests after implementation — post-hoc tests rationalize, don't specify.
- Batch tests then implement — loses red-green feedback loop.
- Skip test execution — unexecuted tests are just comments.

## BDD
`describe` = context; `it` = "should [behavior]". Name by behavior not implementation. Body: given → when → then. One assertion; independent; deterministic.

## Workflow
1. Restate requirement → smallest testable increments
2. Outer: failing acceptance test (stays red across unit cycles)
3. Inner: Red→Green→Refactor until acceptance green
4. Refactor whole; full suite; stay green