tdd

name	tdd
description	Use when implementing a behavior change with clear acceptance criteria. Drives the change through Red, Green, Refactor with tests written first. Pairs naturally with the plan skill for non-trivial features.

tdd

Phases

Red

• Write the smallest failing test that expresses the desired behavior.
• Run it. Confirm it fails for the right reason (not an import error).
• Commit the failing test on its own. The diff is the spec.

Green

• Write the minimum production code that turns the test green.
• Resist generalization. The next test will pull the design forward.
• Run the full test suite, not just the new test.

Refactor

• With everything green, tighten the design: extract, rename, deduplicate.
• Re-run the full suite after every refactor step.
• Stop when the next refactor stops paying for itself.

Test naming

should_<behavior>_when_<condition> — readable by a non-author skimming output.

Coverage targets

• Critical paths (auth, payments, data integrity): 100%.
• Business logic: 80% line coverage as a soft floor.
• Glue / framework code: not measured, reviewed by eye.

Anti-patterns

• Writing tests after the code "to keep velocity" — that's not TDD.
• Mocking the system under test.
• Tests that assert implementation details rather than behavior.