Regression Testing

Regression testing is the practice of re-running a suite of existing tests after making a code change, specifically to catch "regressions" — cases where previously working functionality breaks as an unintended side effect of a change meant to do something else entirely. The name distinguishes it from testing new functionality: regression testing is about verifying old behavior still holds, not validating new behavior. In practice, regression testing is largely automated via the same test suites used for other purposes (unit, integration, and end-to-end tests all double as a regression safety net when run on every change), rather than being a wholly separate category of test with its own dedicated test cases, though some teams do maintain a specific "regression suite" targeting historically fragile areas of the codebase. Why it matters for AI/SaaS builders: as a codebase grows, the risk that an unrelated change accidentally breaks something far away in the system grows with it — a shared utility function used in twelve places, a database migration that changes a column's behavior, a dependency upgrade with a subtle breaking change. A comprehensive, fast regression suite run automatically in CI on every change is what makes it safe to keep shipping quickly as the codebase's surface area grows, rather than every change requiring exhaustive manual re-testing of the entire product. This matters especially for AI-agent-driven development: an agent given "add feature X" needs the regression suite as ground truth to confirm it hasn't silently broken feature Y while implementing X. How it works: regression tests are typically just the accumulated body of unit, integration, and end-to-end tests written over a project's life, executed as a full suite (or an intelligently-selected relevant subset, in large codebases with test-impact-analysis tooling) on every pull request via CI. A failing regression test blocks the merge until either the code is fixed or the test itself is updated (if the old behavior was intentionally changed and the test is simply out of date). Worked example: a developer refactors a shared `formatCurrency()` utility function to support a new currency, changing its internal rounding logic slightly for performance. CI automatically runs the full test suite on the pull request; a regression test written months earlier for an unrelated invoicing feature — `expect(formatCurrency(19.995, "USD")).toBe("$20.00")` — fails, because the refactored rounding logic now returns `"$19.99"`. Without this regression test, the rounding change would likely have shipped unnoticed and caused real invoicing discrepancies in production; instead, CI catches it within minutes, the developer fixes the rounding edge case, and the fix is verified before merge.