tddlisted

# Test-Driven Development No production code without a failing test first — a test written after the implementation can only confirm what the code already does, never what it was supposed to do. ## Red-Green-Refactor 1. **RED** — Write one failing test for the next behavior 2. **Verify RED** — Run the test, confirm it fails for the right reason 3. **GREEN** — Write minimal code to pass 4. **Verify GREEN** — Run all tests, all pass 5. **REFACTOR** — Clean up without breaking tests ## Test Command ```bash pytest ``` ## Stack: python **Test runner:** pytest ```python def test_does_expected_thing(): # Arrange # Act result = feature() # Assert assert result == expected ``` ## Rules - One behavior per test - Watch each test fail before implementing - Minimal code to pass — no extra features - Refactor only after green ## Anchor to the Acceptance Criteria (INV-138) Acceptance tests derive from the issue's frozen criteria, not from your interpretation — writing tests from your own reading of the issue is grading your own homework. - Source of truth: the plan's `## Acceptance Criteria` block (`AC-N:` ids frozen verbatim from the issue), never a live re-read of the issue. - Cite the id in the test title: `it('retries 3 times on 5xx (AC-1)', …)` — the reviewer's FIT rubric maps each `AC-N` to the test line that proves it. - State the mapping in the red commit body: "tests map 1:1 to the acceptance criteria of #NNN". - A behavior worth implementing