Prove the test

The failure this prevents: a test passes while the code is still wrong. A test is worth keeping only if it goes red when the change is reverted. Everything here serves that.

The proof: revert the change, watch the committed suite go red

Revert the change under test (the fix line, the new behavior). Run the committed suite. Watch a test go red. Restore. A test you have not watched fail against the real revert has no teeth, and a green you did not earn this way is a guess.

These do not count as the proof:

• a new test that passes: green alone says nothing about what would turn it red
• a manual run or an e2e you watched fail by hand: that is an acceptance check, not a committed guard, so CI still has nothing

If reverting the change leaves the whole suite green, the change is uncovered. Move or add a test until the revert turns something red.

Test the code that changed, not the code beside it

Extracting a helper and testing the helper does not test the caller that changed. If the bug lived in how the caller wires the pieces together, a green helper test is false confidence. This is the helper-vs-caller trap: you tested the extraction, not the integration.