test-driven-developmentlisted

# Test-Driven Development (TDD) ## 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.** ## When to Use **Always:** new features, bug fixes, refactoring, behavior changes. **Exceptions (ask the user):** throwaway prototypes, generated code, configuration files. Thinking "skip TDD just this once"? Stop. That's rationalization. ## The Iron Law ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` Write 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 tests. ## Red-Green-Refactor ### RED — Write Failing Test One minimal test showing what should happen: one behavior, a name that describes it, real code under test (mocks only if unavoidable — a test that only exercises `vi.fn()` chains tests the mock, not the code). ### Verify RED — Watch It Fail **MANDATORY. Never skip.** ```bash pnpm vitest run path/to/test.test.ts ``` Confirm: - Test **fails** (not errors) - Failure message is the one you expected - It fails because the feature is missing (not a typo or bad import) **Test passes?** You're testing 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 passes t