tdd-workflow

# Test-Driven Development ## Overview Write the test first. Watch it fail. Write minimal code to pass. **Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing. **Violating the letter of the rules is violating the spirit of the rules.** ## The Iron Law ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` Wrote code before the test? Delete it. Start over. Don't keep it as "reference", don't "adapt" it while writing tests — delete means delete, implement fresh from the test. ## When to Use Always: new features, bug fixes, refactoring, behavior changes. Thinking "skip TDD just this once"? Stop. That's rationalization. ## Red-Green-Refactor ### RED — write one failing test - One behavior per test, clear name that describes the behavior. - Test real code; mocks only when unavoidable (external services). - Bad: a test whose assertions only exercise the mock, not the code under test. ### Verify RED — watch it fail (MANDATORY, never skip) - Run the test now (go test ./pkg/... or npm test). - Confirm it FAILS (not errors) and fails because the feature is missing — not a typo or compile error. - Test passes immediately? It tests existing behavior — fix the test. - Test errors? Fix the error and re-run until it fails correctly. ### GREEN — minimal code - Write the simplest code that makes the test pass. Nothing extra (YAGNI). - No extra options, no speculative parameters, no "while I'm here" improvements. ### Verify GREEN — watch...