red-green-proof

Topics in the source

• Red-Green-Proof
• Overview
• Workflow
• Proactive Triggers
• Output Format
• Picking the target
• The loop
• 1. Verify the cause. Do not infer it.

A bug is not fixed because the tests pass. A bug is fixed when a test fails without your fix and passes with it, and you have watched it do both. Use this skill when a bug, incident, flaky test, or unproven regression test is under investigation. It applies a strict red-green-red loop: establish the cause, observe a focused test fail, make the smallest fix, then remove the fix and observe the test fail again. The final revert is the proof that the test is actually coupled to the defect. Keep evidence for each phase separate. A test command that exits zero is not evidence that it exercised the defect; record the assertion and the observed failure or success. Do not proceed when the current phase is unobserved. Before changing code, identify the exact test command and expected red signal. After the fix, run that same command without changing its assertions. During the revert, use the same command again and preserve the failure output. Restore the fix before running the broader suite. A pull request adds a regression test but no pre-fix failure is recorded → ask for the red run before calling it coverage. A bug fix changes production code and tests in one step → verify the test fails

This is an excerpt. Refer to the complete source and its current requirements.