tdd

name	tdd
description	Test-driven development with red-green-refactor loop. Use when building features, fixing bugs, refactoring code, or when the user mentions TDD, test-first, or red-green-refactor. Builds one vertical slice at a time.
argument-hint	[feature or bug description]

Test-Driven Development

"Make it work, make it right, make it fast." — Kent Beck

Philosophy

Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.

• Good tests are integration-style: they exercise real code paths through public APIs. They describe what the system does. These survive refactors.
• Bad tests are coupled to implementation. They mock internal collaborators, test private methods. Warning sign: test breaks on refactor but behavior hasn't changed.

See tests.md for examples and mocking.md for mocking guidelines.

Workflow

Copy this checklist and track your progress:

TDD Progress:
- [ ] Identify vertical slices
- [ ] Slice 1: RED → GREEN → REFACTOR
- [ ] Slice 2: RED → GREEN → REFACTOR
- [ ] ... (repeat per slice)
- [ ] All tests pass
- [ ] No dead code or TODOs remain

Identify Vertical Slices

A vertical slice = one complete, observable behavior. NOT a layer.

Bad (Horizontal)	Good (Vertical)
"Set up database tables"	"User can create an account"
"Add API endpoints"	"User can view order history"
"Write tests"	"User receives email on signup"

Order slices by dependency.

RED — Write a Failing Test

1. Write ONE test for the smallest slice
2. Test should: be specific, test behavior not implementation, follow Arrange-Act-Assert
3. Run it. Confirm it fails for the right reason
4. Do NOT write implementation code yet

GREEN — Write Minimum Code

1. Write the simplest code that passes the test
2. Hardcode if needed — elegance comes in refactor
3. Run the test. It must pass.
4. Do NOT add features not tested

REFACTOR — Clean Up

1. Apply Simplicity First: remove duplication, improve naming, extract functions
2. Do NOT change behavior — tests must still pass
3. Run ALL tests after each refactor step
4. Apply Surgical Changes: don't refactor unrelated code

Repeat for Next Slice

Move to the next vertical slice. Each slice is independent and testable on its own.

Anti-Patterns

• Implementation before tests — Defeats the entire purpose
• Testing implementation details — Tests should verify behavior
• Giant tests — One test = one behavior
• Skipping refactor — This is where quality improves
• Over-engineering in green — Write minimum to pass
• Modifying tests to fit implementation — Fix the code, not the test

Integration

• Use /grill before /tdd to align on what you're building
• Use /diagnose when TDD reveals an unexpected issue
• Use /zoom-out when unsure how a slice fits the larger system