tdd-patterns

TDD Patterns

Contract

Iron law: if you did not watch the test fail, you do not know it tests the right thing. Invoked by /flow:start Phase 3 CODE step 3 (per task, before production code) and by /flow:address for behavior-changing fixes; testing.tddMode governs enforcement. Returns, per behavior, three tracked tasks: a RED test with a sourced expected value and a non-degenerate input, GREEN code, REFACTOR with all tests passing. Permitted skips: tddMode=off; tddMode=suggest with tddModeOptOut=true plus an explicit user decision; refactors (existing tests suffice); config changes without behavior change.

Where expected values come from

An expected value is derived from the spec, a reference implementation, hand computation, an existing fixture, or an external standard, and the test states which (test comment; evidence-bundle column Source of expected). Never run the implementation and paste its output as the expectation. A literal with no stated source is a finding.

Inputs must discriminate

Before testing a risky area (the task's Risk areas: rows, from the specification's ### Risk map), state the plausible wrong implementation and choose an input on which right and wrong differ. Degenerate inputs (identical elements, symmetric or palindromic data, zero, one value repeated in every slot, the simplest possible case) are not coverage of order-, position-, or value-sensitive behavior. Bias randomized inputs toward interesting state and code paths rather than one shared rejection path; prefer structured generators over raw bytes.

Red-Green-Refactor

Three tasks per behavior:

TaskCreate("RED: Failing test for {behavior}", "Sourced expectation, discriminating input, fails first.")
TaskCreate("GREEN: Implement {behavior}", "Simplest passing code.")
TaskCreate("REFACTOR: Clean up {behavior}", "All tests still pass.")

A test is RED only when (a) it fails on first run for the intended reason, (b) its expected value has a stated source, and (c) its input is not degenerate for the behavior under test. A test that passes on first write is checked by breaking the implementation deliberately and watching it fail. REFACTOR runs ALL tests after each step; new functionality is a new RED. TaskList confirms the cycle before the next behavior.