Regression Testing Vs Integration Testing: Key Differences

Here is a situation most backend teams have lived through.

A developer changes how the user service formats dates. It is a tiny change: one line, a cleaner ISO format, every unit test still green. The pull request gets approved in five minutes. Two days later, the billing service starts failing to generate invoices, because it was still expecting the old date format from the user service.

Two kinds of testing could have caught that, and they are the subject of this post. Integration testing would have checked that the user service and the billing service still understand each other. Regression testing would have re-run that check after the "tiny" change, before it shipped.

They sound like competitors. They are not. Once you see what each one actually answers, it becomes clear that you want both, and that they work best together.

The short answer

Integration testing checks that separate components, such as services, databases and external APIs, work correctly together. Regression testing checks that features which already worked still work after a change. Integration testing is about what you test: the connections between parts. Regression testing is about when and why you test: after every change, to make sure nothing that used to work is now broken.

That is also why the two overlap so much. Many of the tests in a good regression suite are integration tests.

What integration testing actually checks

Integration testing looks at the seams of your system. A unit test might confirm that a function formats a date correctly. An integration test confirms that when the user service sends that date to the billing service, the billing service can read it and do its job.

Typical integration tests check things like:

• an API writing the right data to its database
• one service calling another with the right payload and handling the response
• your code talking to a third-party API, a message queue or a cache
• what happens when a dependency is slow, returns an error or sends unexpected data

You usually write integration tests when you build or change a connection between components. If you want the full picture, including types and examples, our integration testing guide goes deeper.

What regression testing actually checks

Regression testing asks a simpler, slightly paranoid question: did we just break something that used to work?

"Regression" literally means going backwards. A regression bug is a feature that worked yesterday and does not work today, usually because of a change that looked unrelated. New features, bug fixes, refactors, dependency upgrades and config changes can all cause one.

A regression test is not a special kind of test. It is any existing test that you re-run after a change. Unit tests, integration tests, API tests and end-to-end tests can all be part of a regression suite. What makes them "regression" is the purpose: protecting behaviour that already exists. For the full background, see our guide on what regression testing is, and the different types of regression testing teams use.

Regression testing vs integration testing at a glance

Back to the date format bug

Let us replay the story from the start, this time with both kinds of tests in place.

When the user and billing services were first connected, someone wrote an integration test: create a user, generate an invoice, check that the invoice has the right customer name and date. It passed, and it stayed in the test suite.

Months later, the developer makes the "tiny" date format change. The CI pipeline runs the full regression suite, which includes that old integration test. The test fails, because the billing service can no longer parse the date. The bug is caught on the pull request, not in production.

Notice what happened. The integration test is what knew how to detect the problem. The regression run is what made sure the check happened at the right moment. Neither one alone would have been enough: an integration test that nobody re-runs protects nothing, and a regression suite with no integration tests would have missed a bug that only exists between two services.

How they work together in a real pipeline

In most teams, the relationship looks like this:

1. You write integration tests while building a feature, to confirm the new connections work.
2. Once they pass, those tests join the regression suite, next to unit tests and a few end-to-end tests.
3. Every pull request runs the regression suite. Fast tests run first, slower ones after.
4. Before a release, a wider regression run covers the critical user flows.

So the question is rarely "regression testing or integration testing?". It is usually "which integration tests belong in our regression suite, and how do we keep that suite fast?". Our guide to automated regression testing covers how to keep a growing suite under control, and CI/CD testing covers where it fits in the pipeline.

When you need more integration testing

You probably need more integration tests if:

• most of your production bugs show up between services, not inside them
• you have recently split a monolith into services
• you depend on third-party APIs that change without much warning
• your unit tests are green but staging keeps breaking

When you need more regression testing

You probably need a stronger regression process if:

• fixing one bug regularly creates another one somewhere else
• releases feel risky, so the team ships less often
• refactoring is avoided because "nobody knows what it will break"
• tests exist, but they are not run automatically on every change

If several of these sound familiar, the fix is usually the same: automate the tests you already have and run them on every pull request.

A real example: one recording, both jobs

Here is where it gets practical. With Keploy, the same recorded tests can act as integration tests and as your regression suite, without writing either by hand.

Using Keploy’s Express and MongoDB sample app, you start the app through Keploy and use it like a normal client:

Keploy saves the API request and response as a test case, and the MongoDB calls behind it as mocks. That recorded test is already an integration test: it checks that the API and the database work together to produce the right response.

Now, every time someone changes the code, you replay the recordings:

That replay is your regression test. If a change alters the response or the way the app talks to MongoDB, the test fails and shows you the difference. Add the same command to your CI pipeline and every pull request is checked against real, previously working behaviour. Setup for other languages and frameworks is in the Keploy docs.

Common mistakes

Treating them as either/or. Teams sometimes say "we do regression testing, so we don’t need integration tests". If the regression suite has no tests that cross service boundaries, it cannot catch bugs that live there.

Writing integration tests and never re-running them. A test that only ran once, when the feature was built, gives no protection against the next change.

Letting the regression suite grow until nobody runs it. If the full suite takes an hour, people stop waiting for it. Split it: fast unit and integration tests on every pull request, the slower end-to-end tests before release.

Relying only on end-to-end tests for regression. They are slow and flaky, and when they fail they rarely tell you where the problem is. Integration tests point much closer to the cause.

Tools that help with both

• Keploy: records real API traffic into test cases and mocks, then replays them on every change, so the same tests cover integration and regression.
• Postman: API checks that can be re-run as a regression collection.
• Testcontainers: real databases and services in containers for integration tests.
• Selenium and Playwright: end-to-end regression checks through the UI.
• Jenkins, GitHub Actions and GitLab CI: run the whole suite automatically on every change.

For longer lists, see our roundups of regression testing tools and integration testing tools.

Related comparisons

If you are sorting out testing terms, these comparisons are worth reading next:

• Unit testing vs regression testing
• Integration testing vs functional testing
• Smoke testing vs regression testing

Conclusion

Integration testing and regression testing answer different questions. Integration testing asks whether your components work together. Regression testing asks whether your latest change broke something that used to work. In practice, they meet in the middle: your integration tests become part of your regression suite, and running that suite on every change is what stops "tiny" changes from turning into production incidents.

If you want both without writing hundreds of tests by hand, try Keploy for API testing and turn real traffic into tests you can replay on every pull request.

FAQs

What is the difference between regression testing and integration testing?

Integration testing checks that separate components work correctly together. Regression testing checks that existing features still work after a change. Integration testing is defined by its scope, the connections between components, while regression testing is defined by its purpose, re-checking after changes.

Is integration testing a type of regression testing?

No, but integration tests are often part of a regression suite. An integration test becomes a regression test when you re-run it after a change to make sure the connection it covers still works.

Which comes first, integration testing or regression testing?

Integration testing usually comes first, while a feature is being built. Regression testing comes after changes are made, and it re-runs existing tests, including those integration tests, to catch anything that broke.

Can regression testing be done at the integration level?

Yes. Integration regression testing means re-running integration tests after a change, to make sure components still work together. It is one of the most effective kinds of regression testing for microservices and API-heavy systems.

What is the difference between unit, integration and regression testing?

Unit testing checks one function or class in isolation. Integration testing checks that connected components work together. Regression testing re-runs existing tests, at any of these levels, after a change to make sure nothing that worked before is now broken.

Should regression tests be automated?

Yes, in almost every case. A regression suite runs after every change, so running it by hand quickly becomes too slow and too easy to skip. Automated regression tests in a CI/CD pipeline catch problems on the pull request, before they reach users.