Quality-First TDD
Priority: P0 (CRITICAL)
A passing test is insufficient; the test must prove an owned behavior and a distinct plausible fault.
Choose the mode
- New behavior: strict RED -> GREEN -> REFACTOR. Do not write production code before the expected RED.
- Legacy or bug fix: characterize only when needed, then reproduce the intended change as a failing regression (RED). Preserve unrelated existing code; do not delete it merely because it predates the test.
Before writing a test
Create one Test Intent Record per behavior/risk:
contract: observable contract — an application-owned result or side effect
fault: distinct fault — a distinct plausible regression this test would catch
layer: smallest honest unit, component, contract, integration, or E2E layer
cases: minimal distinct equivalence classes; use a parameterized test for equivalent inputs
command: exact focused single-run command
Reject tests that duplicate an existing fault, assert implementation detail or mock choreography, depend on time/network/order, or force a broader behavior into a unit.
Bounded loop
- Run configured lint/type checks, inspect nearby tests, and derive the smallest command.
- RED: add one intent group and run it in the foreground, sequentially, single-run mode.
- Classify RED as
expected_red, invalid_red, unexpected_green, or verification_infra_failed. If it is unexpected_green, inspect existing coverage and remove a redundant or weak case before implementing production code.
- GREEN: implement only enough to satisfy
expected_red; rerun the same command.
- REFACTOR: improve structure without changing behavior; rerun the same command.
- Escalate only when evidence requires it: related unit target, integration/contract target, then explicit release/full-suite gate.
Execution safety
- Honor project timeouts; otherwise use a 120-second fallback to bound a focused command.
- On timeout, terminate only the agent-owned process group and verify child cleanup.
- Never watch, blanket-kill, or retry an unchanged failure. Record the new hypothesis or corrective change first.
- Coverage is repository-configured, project-owned evidence. Without a configured threshold, report risk gaps and never add padding tests for a percentage.
Red flags and rationalizations
- Stop on:
add tests after, too small, passed first run, run the full suite again, or mock every collaborator.
- Urgency, manual testing, test count, or a coverage target never bypasses the intent record, expected RED, bounded command, or fault proof.
Test shape
- Use clear Arrange, Act, Assert phases; comments are optional.
- Assert observable outcomes. Assert an interaction only when that interaction is the contract.
- Mock external boundaries only when isolation requires it; prefer real pure/domain behavior and simple fakes.
- Keep test names behavior-focused, without ticket IDs or TODO/FIXME markers.
See references/quality-contract.md for the intent record, failure taxonomy, layer routing, and runner examples.
1---2name: common-tdd3description: "Guides quality-first TDD for new behavior, bug fixes, and test changes. Selects the smallest test layer, proves a distinct regression risk, and runs bounded RED-GREEN-REFACTOR verification."4metadata:5 triggers:6 files:7 - "**/*.test.ts"8 - "**/*.spec.ts"9 - "**/*_test.go"10 - "**/*Test.java"11 - "**/*_test.dart"12 - "**/*_spec.rb"13 keywords:14 - tdd15 - unit test16 - write test17 - red green refactor18 - failing test19 - test coverage20---2122# Quality-First TDD2324## **Priority: P0 (CRITICAL)**2526A passing test is insufficient; the test must prove an owned behavior and a distinct plausible fault.2728## Choose the mode2930- **New behavior:** strict RED -> GREEN -> REFACTOR. Do not write production code before the expected RED.31- **Legacy or bug fix:** characterize only when needed, then reproduce the intended change as a failing regression (RED). Preserve unrelated existing code; do not delete it merely because it predates the test.3233## Before writing a test3435Create one Test Intent Record per behavior/risk:3637- `contract`: observable contract — an application-owned result or side effect38- `fault`: distinct fault — a distinct plausible regression this test would catch39- `layer`: smallest honest unit, component, contract, integration, or E2E layer40- `cases`: minimal distinct equivalence classes; use a parameterized test for equivalent inputs41- `command`: exact focused single-run command4243Reject tests that duplicate an existing fault, assert implementation detail or mock choreography, depend on time/network/order, or force a broader behavior into a unit.4445## Bounded loop46471. Run configured lint/type checks, inspect nearby tests, and derive the smallest command.482. **RED:** add one intent group and run it in the foreground, sequentially, single-run mode.493. Classify RED as `expected_red`, `invalid_red`, `unexpected_green`, or `verification_infra_failed`. If it is `unexpected_green`, inspect existing coverage and remove a redundant or weak case before implementing production code.504. **GREEN:** implement only enough to satisfy `expected_red`; rerun the same command.515. **REFACTOR:** improve structure without changing behavior; rerun the same command.526. Escalate only when evidence requires it: related unit target, integration/contract target, then explicit release/full-suite gate.5354## Execution safety5556- Honor project timeouts; otherwise use a 120-second fallback to bound a focused command.57- On timeout, terminate only the agent-owned process group and verify child cleanup.58- Never watch, blanket-kill, or retry an unchanged failure. Record the new hypothesis or corrective change first.59- Coverage is repository-configured, project-owned evidence. Without a configured threshold, report risk gaps and never add padding tests for a percentage.6061## Red flags and rationalizations6263- Stop on: `add tests after`, `too small`, `passed first run`, `run the full suite again`, or `mock every collaborator`.64- Urgency, manual testing, test count, or a coverage target never bypasses the intent record, expected RED, bounded command, or fault proof.6566## Test shape6768- Use clear Arrange, Act, Assert phases; comments are optional.69- Assert observable outcomes. Assert an interaction only when that interaction is the contract.70- Mock external boundaries only when isolation requires it; prefer real pure/domain behavior and simple fakes.71- Keep test names behavior-focused, without ticket IDs or TODO/FIXME markers.7273See `references/quality-contract.md` for the intent record, failure taxonomy, layer routing, and runner examples.