tdd-failing-tests-loop

A strict red-green-refactor loop mitigates risk by mapping the existing contract first, writing purposeful failing tests to express gaps, and making the smallest green changes to satisfy the new contract before refactoring. This keeps tests, implementation, and documentation aligned.

Write purposeful red tests that explicitly express contract gaps in the targeted surface area. By mapping the existing contract first, you capture the durable behavior boundaries, allowing your failing tests to clarify ambiguous expectations before you make the smallest green change to satisfy them.

Use a failing-tests-first workflow for subsystem overhauls when behavior is brittle, tests are ambiguous, or documentation must stay aligned with implementation. It enforces steps to map the contract, write red tests, run the smallest green changes, and synchronize docs to produce a traceable red to green timeline.

Sync internal docs, prompts, and policy to reflect the new runtime contract after your code turns green. This loop ensures that your documentation stays aligned with the implementation throughout the refactor, capturing the auditable red to green timeline for your subsystem overhaul.

Yes, you run the smallest relevant test slice to verify the targeted surface area. This focused execution verifies your smallest green changes efficiently before you broaden verification to adjacent subsystems and related suites, ensuring the contract gaps are resolved without unnecessary overhead.

Your TDD workflow fails when you skip mapping the contract or syncing documentation after refactoring. A traceable red to green timeline requires enforcing steps to map the contract, write failing tests, make green changes, and record the progression to verify the targeted surface and adjacent subsystems.