What is Regression Testing?

Regression testing is the practice of rerunning existing tests after a code change to verify that previously working functionality still works. When you fix a bug, add a feature, or refactor code, regression tests catch any side effects that break behavior somewhere else in the system. The name comes from the fact that bugs which reappear after they were supposedly fixed are called 'regressions' — and the tests exist to catch them.

On every pull request, before merge. Running them only on main means regressions are caught after they have already landed, at which point fixing them takes longer and blocks other work. Modern teams gate the merge button on the regression suite result so broken code cannot merge. For very large codebases where the full suite takes too long to run on every PR, selective regression testing uses the changed files to pick a subset of tests most likely to catch an issue.

They are not mutually exclusive — regression testing is a use case, unit testing is a technique. Unit tests catch logic bugs in individual functions; they become part of the regression suite when they run on every PR. Integration tests and end-to-end tests catch boundary bugs and user-journey bugs; they also become part of regression testing when they run automatically. The distinction is that regression testing describes WHY you run tests (to catch breakages in existing functionality), while unit / integration / E2E describe WHAT tests you run.

Suite growth. A service that has been in production for two years typically has thousands of accumulated test cases, and running them all on every PR becomes a bottleneck. Teams respond in three ways: parallelization (run tests across multiple workers), selective testing (pick a subset based on what changed), and test consolidation (delete tests that have not caught a bug in the last 12 months). Getting the right trade-off between suite breadth and suite speed is the recurring tuning problem for regression testing at scale.

Keploy captures real HTTP, gRPC, WebSocket, and database traffic flowing through your running service using eBPF at the Linux kernel level. Every captured request becomes a YAML test case with auto-generated mocks for every downstream dependency. On every PR, Keploy replays the committed fixtures against the rebuilt service and fails the build on any behavior change. Unlike hand-written tests that cover what a developer thought to check, Keploy covers what users actually did — which is typically a broader and more meaningful regression surface.

Yes, selectively. A regression test that has not caught a real bug in 12-24 months is either redundant with a newer test or covers dead code. Teams that treat their test suite as read-only end up running thousands of tests that add noise and maintenance burden without catching new regressions. The discipline to delete is what keeps a regression suite effective at scale. Keep tests that have caught real bugs (they have proven their value) and delete tests that cover paths the code no longer takes.