| name | test-driven-development |
| description | Use when implementing any feature or bugfix, before writing implementation code |
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.
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Red-Green-Refactor
RED - Write Failing Test
Write one minimal test showing what should happen. One behavior, clear name, real code.
Verify RED - Watch It Fail
MANDATORY. Test must fail for expected reason (feature missing, not typos).
GREEN - Minimal Code
Write simplest code to pass the test. Don't add features beyond the test.
Verify GREEN - Watch It Pass
MANDATORY. Test passes, other tests still pass, output pristine.
REFACTOR - Clean Up
After green only. Remove duplication, improve names, extract helpers. Keep tests green.
Good Tests
- Minimal: One thing per test
- Clear: Name describes behavior
- Shows intent: Demonstrates desired API
Common Rationalizations
- "Too simple to test" - Simple code breaks. Test takes 30 seconds.
- "I'll test after" - Tests passing immediately prove nothing.
- "Already manually tested" - Ad-hoc ≠ systematic.
- "Deleting X hours is wasteful" - Sunk cost fallacy.
Red Flags - STOP and Start Over
Code before test, test passes immediately, "just this once", "keep as reference".
Example: Bug Fix
RED: Write test for empty email rejection.
Verify RED: Test fails with expected message.
GREEN: Add validation check.
Verify GREEN: Test passes.
REFACTOR: Extract validation if needed.
