Regression Testing
Regression testing re-runs existing tests after a change to confirm that previously working behaviour still works.
Definition
Regression testing is the practice of re-executing tests that encode known-good behaviour whenever code changes, to catch unintended breakage before release. It is not a distinct kind of test but a purpose: any test can be a regression test if it guards a behaviour that once worked. Because suites grow, mature teams select and prioritise — running fast critical tests on every change and the full suite less often — rather than rerunning everything blindly.
Context and scope
Every change to an existing system risks breaking something that worked; regression testing is the automated safety net against that.
Common misconceptions
- Regression tests are a separate suite — regression is a purpose, so the same tests serve as regression guards once pinned
- More regression tests are always better — a large slow suite delays feedback and erodes the discipline it depends on
- Passing regression tests means no bugs — they protect only what they encode; new or unasserted behaviour is still open
Anti-patterns
- Deleting or skipping a failing regression test to unblock a release instead of fixing or consciously updating it
- Re-running the entire suite on every commit until developers stop waiting for it
- Keeping tests that assert incidental implementation details, so every refactor triggers false failures
Related concepts
Authoritative source
What it is
Regression testing confirms that a change did not break behaviour that used to work. The tests themselves are ordinary unit, integration, or end-to-end tests; what makes them regression tests is that they are retained and re-run as the system evolves. A bug fix usually adds one, so the specific defect can never silently return. The suite is therefore a growing record of promises the system has kept.
Why it matters
Most changes to a live system are meant to be local but are not: a shared helper changes and a distant feature breaks. Regression testing catches this before users do, and it does so automatically and repeatably. It is what lets teams refactor and upgrade dependencies with confidence, and it converts the question “did I break anything” from a hope into a signal.
How to use it well
Tie tests to observable behaviour rather than internal structure, so they stay valid across refactors. Prioritise: run fast, high-value tests on every change, and schedule slower end-to-end suites where they will not block feedback. When a regression test fails, treat it as evidence and investigate before changing or skipping it — a quietly deleted failing test is how a known defect returns.