Regression Testing

What Is Regression Testing?

Regression testing is the practice of re-running a suite of existing tests after every code change to verify that new modifications have not broken previously working functionality. The term “regression” refers to a software defect where a feature that was working correctly starts failing after an unrelated change is introduced.

Regressions are among the most frustrating bugs in software development. A developer modifies the payment processing module, and the user profile page starts crashing. A performance optimization to the search algorithm causes sorting to return results in the wrong order. These failures are unintuitive because the developer did not intentionally touch the broken feature. Regression testing exists to catch these unintended side effects before they reach production.

In modern development workflows, regression testing is almost entirely automated. Teams maintain a suite of unit tests, integration tests, and end-to-end tests that run in continuous integration (CI) pipelines on every commit or pull request. When a test that was previously passing starts failing, the CI pipeline flags a regression, and the developer can investigate the failure before merging the change.

How It Works

Regression testing does not require special test types or tools — it is a strategy applied to existing tests. The key mechanism is running the full test suite (or a relevant subset) after every change to detect whether something that previously worked has stopped working.

A typical CI-driven regression testing workflow looks like this:

# .github/workflows/regression.yml
name: Regression Tests
on: [pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run test:unit
      - run: npm run test:integration
      - run: npm run test:e2e

When a developer pushes a change, CI runs all tests. If any previously passing test fails, the PR is blocked:

FAIL src/cart/cart.test.js
  ✓ adds item to cart (3 ms)
  ✓ removes item from cart (2 ms)
  ✗ calculates total with tax (5 ms)
    Expected: 107.50
    Received: 100.00

  ● calculates total with tax
    The tax calculation was inadvertently removed during refactoring.

In Python, the same principle applies. Running the full test suite after every change catches regressions immediately:

# test_cart.py
class TestCart(unittest.TestCase):
    def test_total_includes_tax(self):
        cart = Cart()
        cart.add_item(Item("Widget", price=100.00))
        cart.set_tax_rate(0.075)
        # This test catches the regression if tax logic is removed
        self.assertAlmostEqual(cart.total(), 107.50)

Some teams implement selective regression testing, where only the tests related to the changed files are run. Tools like Jest’s --changedSince flag, pytest’s --lf (last failed) mode, or Bazel’s dependency graph analysis enable this approach, dramatically reducing feedback time on large codebases.

Why It Matters

Software systems are interconnected. A change in one module can trigger failures in seemingly unrelated modules through shared state, inherited behavior, global configuration, or data dependencies. Without regression testing, these failures go undetected until a user reports them in production.

The cost of regressions compounds over time. A team that ships a regression today might not hear about it until next week, by which point several more changes have been built on top of the broken code. Finding and fixing the root cause becomes an archaeological exercise of bisecting commits and reverting changes. Automated regression testing prevents this cascade by catching breakages within minutes of their introduction.

Regression testing also enables confident refactoring. When a team knows that every change is validated against the full test suite, developers can restructure code, upgrade dependencies, and optimize performance without fear that they are silently breaking something. This keeps the codebase healthy and maintainable over the long term.

Best Practices

• Run regression tests on every pull request. Do not defer testing to a nightly build. Developers need immediate feedback so they can fix regressions while the change is still fresh in their minds.
• Prioritize test stability. A regression test suite filled with flaky tests is worse than useless — it trains developers to ignore failures. Fix or quarantine flaky tests immediately.
• Add a regression test for every bug fix. When you fix a bug, write a test that reproduces it. This ensures the specific bug never reappears, even as the codebase evolves.
• Use test impact analysis. On large codebases, running every test on every change can be slow. Use tools that map code changes to affected tests and run only those tests, with a full suite run on merge to main.
• Maintain test suite speed. If the regression suite takes 30 minutes, developers will push multiple changes between runs, making it harder to identify which change caused a failure. Keep the suite under 10 minutes by parallelizing tests and optimizing slow ones.

Common Mistakes

• Deleting failing tests instead of fixing regressions. When a test fails after a code change, the correct response is to investigate whether the change introduced a bug or whether the test needs updating. Deleting the test because “it does not match the new behavior” without understanding why it changed is how regressions slip into production.
• Running regression tests only before releases. Teams that batch all testing before a release end up with dozens of regressions to investigate simultaneously, with no clear link between individual changes and specific failures. Continuous regression testing on every commit is far more effective.
• Ignoring slow test suite growth. As a codebase grows, the regression suite grows with it. Without periodic optimization — removing redundant tests, parallelizing execution, improving test infrastructure — the suite becomes so slow that developers stop waiting for it to complete.
• Testing only the changed module. A change to the authentication module might break the checkout flow if they share session state. Running tests only for the changed module gives a false sense of safety. Always run the full suite, or use dependency-aware test selection tools.