tddlisted

# Test-Driven Development Try to write the test first. Not always possible, but always the goal. ## Progress Checklist - [ ] Detect test framework and patterns - [ ] Write failing test (RED) - [ ] Write minimal code to pass (GREEN) - [ ] Refactor with tests green (REFACTOR) - [ ] Repeat for next behavior ## Step 0: Detect Test Framework ```bash # Check project for test setup cat package.json 2>/dev/null | grep -E "jest|vitest|mocha|testing" ls *test* *spec* **/*.test.* **/*.spec.* 2>/dev/null | head -10 cat go.mod 2>/dev/null | grep testing ls *_test.go 2>/dev/null | head -5 ``` Match the project's existing patterns: test location, naming convention, setup/teardown approach. ## The Cycle ### RED: Write a Failing Test Write a test that describes the behavior you want. Run it. It should fail. If it passes without you writing any implementation, either: - The behavior already exists (check before writing) - The test is wrong (it's testing nothing useful) The test name should describe the behavior, not the implementation: - Good: `should reject expired tokens` - Bad: `test validateToken function` ### GREEN: Make It Pass Write the **minimum** code to make the test pass. Don't over-engineer. Don't add features the test doesn't require. This feels wrong but it's the point - the tests drive what gets built. ### REFACTOR: Clean Up With all tests green, improve the code: - Remove duplication - Improve naming - Simplify logic - Extract patterns Run tests after each chang