Regression Testing: Don't Break What's Already Working

Why it exists

Software is complex and interconnected. A change in one module can have ripple effects, breaking seemingly unrelated functionality. Regression testing was created to systematically detect these "regressions"—when a feature that used to work stops working after a change. It provides confidence that a new feature or bug fix doesn't come at the cost of existing stability.

The mental model

Think of it like a doctor prescribing a new medication. They don't just check if the new drug treats the target symptom; they also run standard tests (blood pressure, heart rate) to ensure it isn't causing harmful side effects elsewhere in the body. Regression testing is that standard checkup for your codebase after you've introduced a change. It verifies that the "patient" (your application) is still healthy overall.

How it works

After a developer commits a change, an automated system like a CI/CD pipeline triggers a pre-defined set of tests. These are not new tests for the new feature, but a curated collection of existing functional and non-functional tests covering the application's core functionality. If any test that previously passed now fails, the build is marked as "broken," and the change is blocked from proceeding to production until the regression is fixed.

When to use it

Regression testing is essential in any project with a continuous delivery model. It should be an automated step in your CI/CD pipeline that runs on every merge to the main branch. It's also critical before major releases or when refactoring large, sensitive parts of the codebase. The goal is to catch regressions as early as possible, when they are cheapest to fix.

When not to use it

You don't run the full regression suite for every single keystroke while developing locally; that would be too slow. Instead, developers might run a smaller, targeted subset of tests relevant to their changes. The full suite is reserved for integration points, like pull requests. The key is balancing test coverage with feedback speed.

One canonical example

A developer fixes a bug on a user profile page by changing a shared CSS file. The new test confirms the fix. However, when the code is merged, the automated regression suite runs. A test for the checkout page, which also uses that CSS file, now fails because the "Proceed to Payment" button has disappeared. This is a classic regression caught before it reached a customer.