test-driven-development

Test-Driven Development

Core Principle

If you did not watch the test fail, you do not know whether it tests the behavior.

IRON LAW

No production behavior change without a failing test first, unless the user explicitly approves an exception.

Red-Green-Refactor

1. RED: Write one minimal test for one observable behavior.
2. Verify red: Run it and confirm it fails for the expected reason.
3. GREEN: Write the smallest production change that passes.
4. Verify green: Run the focused test and relevant surrounding tests.
5. REFACTOR: Clean names, duplication, and structure while keeping tests green.

Good Test Rules

• Test external behavior, not implementation details.
• One behavior per test; split tests with “and” in the name.
• Prefer real code paths over mocks unless isolation is necessary.
• Regression tests must fail when the fix is removed.

Allowed Exceptions

Ask before skipping TDD for:

• Throwaway prototypes.
• Pure config or docs changes.
• Generated code.
• UI-only visual polish where screenshot/browser verification is the stronger evidence.

Output Contract

## Behavior Under Test
## Red Evidence
## Green Evidence
## Refactor Notes
## Exceptions