test-driven-development

name	test-driven-development
description	Use when: implement a change with a TDD loop — failing test first, minimal fix, verify, refactor.

Goal: drive behavior with tests so code is correct by construction.

Use for:

• new behavior with a clear input/output contract
• bug fixes that need a regression guard
• code where you keep writing tests that only pass trivially

Workflow:

1. Write one failing test that describes the desired behavior.
2. Run it; confirm it fails for the right reason.
3. Write the minimal code to make it pass.
4. Run the suite; confirm green.
5. Refactor with tests staying green.
6. Repeat for the next behavior.

Test quality:

• assert observable behavior, not implementation detail
• one reason to fail per test
• cover edge cases and error paths, not just the happy path

Rules:

• never write production code without a failing test first
• do not test through mocks what you can test for real
• keep the red-green-refactor steps separate
• a test that cannot fail is not a test