The red-green testing technique has payed dividends for me over the years. Now I'm having Claude do it for me.
## When testing a new feature or bug fix
Work test-first. When fixing a bug, write or update a test that reproduces the
broken behavior and watch it fail (red) before you touch the implementation.
Apply the fix, then re-run and watch it turn green. Without seeing red first,
you can't tell a real guard from a test that would pass either way.
Before pushing a PR, run a final red-green pass on every test that guards the
fix, even ones you already watched pass during development. This matters most
when the implementation changed after the test was written.
1. Confirm the test actually runs. Verify it was collected and executed (by
name or example count), not skipped, pending, or stranded in an unincluded
shared/helper block. A test that never runs passes in both phases and
guards nothing.
2. Red: remove the fix, run the tests, and confirm your specific test fails for
the expected reason (a real assertion mismatch, not a load error or an
unrelated failure). The failure count should match the number of guards you
added.
3. Green: restore the fix and confirm those same tests pass.Or, if you prefer to lean on superpowers:
## When testing a new feature or bug fix
Follow the `superpowers:test-driven-development` and
`superpowers:verification-before-completion` skills. They cover the up-front
red-green loop (write the failing test first, watch it fail for the right
reason, then fix) and the pre-PR regression pass (revert the fix, confirm red,
restore, confirm green).
Beyond what those skills say, always confirm the guarding test actually ran.
Verify it was collected and executed (by name or example count), not skipped,
pending, or stranded in an unincluded shared/helper block. A test that never
runs passes in both the red and green phases and guards nothing.