tdd

name	tdd
description	AI DevKit · Test-driven development — write a failing test before writing production code. Use when implementing new functionality, adding behavior, or fixing bugs during active development.

TDD

Red. Green. Refactor. In that order, every time.

Hard Rules

• No production code without a failing test first.
• If production code was written before its test, delete it and start over with a failing test.
• Never skip the red step. A test that has never failed proves nothing.

Cycle

For each unit of behavior:

1. Red — Write a test for the next behavior. Run it. It must fail. Read the failure message — it should describe the missing behavior.
2. Green — Write the minimum production code to make the test pass. Nothing more. Run the test. Apply the verify skill.
3. Refactor — Clean up both test and production code. Run the test again. Still green? Done. Apply the verify skill.

Then pick the next behavior and repeat.

Rules for Each Step

Red:

• Test one behavior, not one function. Name the test after what the system should do, not what the function is called.
• The test must fail for the right reason — a missing method, wrong return value, unmet condition. Not a syntax error or import failure.
• If the test passes immediately, it's not testing new behavior. Delete it or pick a different behavior.

Green:

• Write the simplest code that passes. Hardcode if needed — the next test will force generalization.
• Do not add code "while you're in there." If it's not required by a failing test, it doesn't exist yet.
• Do not refactor during green. Pass first, clean second.

Refactor:

• Remove duplication between test and production code.
• Extract only when you see real duplication, not predicted duplication.
• Tests must still pass after every refactor move. Run them after each change.

Anti-Patterns

Pattern	Problem	Fix
Test-after	Code shapes the test instead of the other way around	Delete the code, write the test first
Testing internals	Tests break on refactor, not on behavior change	Test public behavior only
Giant red step	Multiple behaviors in one test	One assertion per behavior
Gold-plating green	Adding code no test requires	Remove untested code
Skipping refactor	Tech debt accumulates immediately	Refactor before the next red
Mock-heavy tests	Tests pass but real code fails	Prefer real dependencies, mock at boundaries only

Red Flags and Rationalizations

Rationalization	Why It's Wrong	Do Instead
"This is too simple to test first"	Simple code still needs a spec	Write the test — it'll be fast
"I'll add the test right after"	You won't, and the code will shape the test	Test first, always
"I need to see the design first"	The test IS the design	Let the test drive the interface
"Mocking is too hard for this"	Difficulty mocking signals tight coupling	Fix the design, then test
"The test would be identical to the implementation"	Then you're testing internals	Test the behavior from the outside

Memory Integration

After completing a TDD session, store reusable test patterns (setup, assertions, fixtures): npx ai-devkit@latest memory store --title "<pattern>" --content "<details>" --tags "tdd,testing"