Regression test
A test written from a specific bug so that exact bug can never come back unnoticed. See it fail first, then fix, then keep it forever.
See it
What it is
A regression is old behavior that used to work and now does not. A regression test is the tripwire you leave behind after fixing one, written from the actual bug rather than from the spec. The recipe: reproduce the bug, turn the reproduction into the smallest test that fails because of it, watch it go red, apply the fix, watch it go green. Name it after the symptom or the issue number so the next person knows why this odd little test exists.
The word does double duty. A 'regression suite' also means the whole accumulated body of existing tests, rerun before every release to confirm that new work did not break old work. Both senses share one idea: you are defending behavior that already shipped.
Gotcha: writing the test after the fix and never seeing it fail proves nothing. Plenty of 'regression tests' pass against the broken code too, because they assert on the wrong layer. Revert your fix locally, confirm red, then reapply. Also write the test at the lowest level that still reproduces the bug: a unit test that pins the off-by-one beats an end-to-end script that clicks through six screens to reach it.
Ask AI for it
Write a regression test for this bug before fixing it. Start from the reproduction steps, pick the lowest level that still reproduces the failure (unit if possible, integration if it needs the database, E2E only if it is a real browser behavior), and assert on the specific wrong value or wrong state the bug produces. Name the test after the symptom and reference the issue number in a comment. Show me the test failing against the current code first, then the minimal fix that turns it green.