TDD
Test-driven development for greenfield code: behavior that has never
existed and has no prior failing state to reproduce. The discipline is red,
green, refactor — write a test that fails because the behavior does not
exist yet, write the smallest implementation that makes it pass, then
clean up with the test still green. This is the broader discipline that
failing-test-first is one instance of; that skill owns the narrower,
already-rostered case of reproducing an existing bug with a test before
fixing it. Where the two could both apply — extending existing code with a
new capability that isn't a bugfix — this skill governs; where a defect in
already-working code is being reproduced, failing-test-first governs, not
this one.
Reach for this when
- Building a new function, endpoint, component, or feature that does not
exist in the codebase yet.
- Extending existing code with new behavior that has never run before (a
new branch of logic, a new parameter's effect, a new command).
- The user asks to "test-drive" or "TDD" a piece of new work.
Do not reach for it when:
- A bug, defect, regression, or wrong output is being fixed in code that
used to work — that is
failing-test-first; write the reproduction
first, but follow that skill's contract, not this one.
- The change is a pure refactor with no behavior change — there is nothing
new to write a failing test against; the existing suite is the check.
Red
Write the test for the behavior you are about to build, against the
interface you intend it to have, before writing that implementation. Run
it and confirm it fails for the reason you expect — a missing function, an
unimplemented branch, an assertion on behavior that does not exist — not
for an unrelated reason (a typo, an import error, a fixture that doesn't
build). A red test that fails for the wrong reason proves nothing about
the behavior you're adding.
Green
Write the smallest implementation that makes the test pass. Resist adding
behavior the test doesn't ask for — extra parameters, extra branches,
speculative generality — even if you can predict a future need for them.
Run the test and confirm it now passes, and run the surrounding suite to
confirm nothing else broke.
Refactor
With the test green, clean up: remove duplication, rename for clarity,
extract what deserves extracting. Run the suite after each change. If a
refactor requires a behavior change to work, that is new red-green work,
not refactoring — stop and go back to red.
Keep the test
The test stays in the suite after the feature ships. It is now a
regression check for behavior that, before this skill ran, did not exist
to regress.
1---2name: tdd3description: Write a failing test for new behavior before implementing it, then implement only enough to pass, then refactor — red, green, refactor for code that has never worked yet. Use when building a new feature, function, endpoint, or component from scratch and no prior bug is being reproduced. Not for fixing a bug, defect, regression, or wrong output in existing code — that is failing-test-first, which owns the bugfix case specifically; defer to it whenever a prior working state exists to reproduce a break against.4---56# TDD78Test-driven development for **greenfield** code: behavior that has never9existed and has no prior failing state to reproduce. The discipline is red,10green, refactor — write a test that fails because the behavior does not11exist yet, write the smallest implementation that makes it pass, then12clean up with the test still green. This is the broader discipline that13`failing-test-first` is one instance of; that skill owns the narrower,14already-rostered case of reproducing an existing bug with a test before15fixing it. Where the two could both apply — extending existing code with a16new capability that isn't a bugfix — this skill governs; where a defect in17already-working code is being reproduced, `failing-test-first` governs, not18this one.1920## Reach for this when2122- Building a new function, endpoint, component, or feature that does not23 exist in the codebase yet.24- Extending existing code with new behavior that has never run before (a25 new branch of logic, a new parameter's effect, a new command).26- The user asks to "test-drive" or "TDD" a piece of new work.2728Do not reach for it when:2930- A bug, defect, regression, or wrong output is being fixed in code that31 used to work — that is `failing-test-first`; write the reproduction32 first, but follow that skill's contract, not this one.33- The change is a pure refactor with no behavior change — there is nothing34 new to write a failing test against; the existing suite is the check.3536## Red3738Write the test for the behavior you are about to build, against the39interface you intend it to have, before writing that implementation. Run40it and confirm it fails for the reason you expect — a missing function, an41unimplemented branch, an assertion on behavior that does not exist — not42for an unrelated reason (a typo, an import error, a fixture that doesn't43build). A red test that fails for the wrong reason proves nothing about44the behavior you're adding.4546## Green4748Write the smallest implementation that makes the test pass. Resist adding49behavior the test doesn't ask for — extra parameters, extra branches,50speculative generality — even if you can predict a future need for them.51Run the test and confirm it now passes, and run the surrounding suite to52confirm nothing else broke.5354## Refactor5556With the test green, clean up: remove duplication, rename for clarity,57extract what deserves extracting. Run the suite after each change. If a58refactor requires a behavior change to work, that is new red-green work,59not refactoring — stop and go back to red.6061## Keep the test6263The test stays in the suite after the feature ships. It is now a64regression check for behavior that, before this skill ran, did not exist65to regress.
jonhill90