Next-Gen App & Browser Testing Cloud

Trusted by 2 Mn+ QAs & Devs to accelerate their release cycles

When Should You Run Integration Testing?

Run integration testing right after unit tests pass and your modules are ready to be combined, continuously in CI on every merge, and before system or end-to-end testing. You should also trigger it after significant refactors and whenever you wire in a new third-party service or API. The goal is simple: catch broken interactions between components as early and as often as possible, not at the end of a release when they are expensive to fix.

Below we break down each trigger point in detail, show where integration testing sits in the test pyramid and SDLC, and explain how to wire it into your CI/CD pipeline. For the fundamentals, see this guide on Integration Testing.

What Is Integration Testing?

Integration testing is the level of testing where individually verified modules are combined and tested as a group to expose defects in the way they interact. Unit tests prove that each function or class works on its own; integration tests prove that those units exchange data, call each other, and share state correctly when joined together.

Most integration bugs live at the boundaries: a mismatched API contract, a wrong data format passed between services, a database schema that drifted out of sync, or a third-party response your code never expected. None of these show up in a unit test because a unit test mocks the other side. Integration testing removes those mocks, at least partially, and checks the real conversation between components.

When to Run Integration Testing

There is no single moment to run integration testing — there are several recurring triggers. The healthiest teams run a fast integration suite continuously and reserve heavier runs for specific milestones. Here is each trigger and why it matters:

After unit testing passes. Unit tests are your first, fastest gate. Once the modules involved in a feature pass their unit tests, run integration tests to confirm those modules cooperate. Running integration tests on code that still fails unit tests just wastes time debugging combined failures a unit test would have isolated.
On each CI merge (continuously). Wire integration tests into your pipeline so they fire on every pull request and every merge to the main branch. This catches contract breaks within minutes of the change that caused them, while the author still has full context, instead of weeks later during a release crunch.
Before system and end-to-end testing. System, performance, and end-to-end tests assume the application is already wired together correctly. Run integration testing first so you are not chasing low-level interface bugs while trying to validate a full user journey.
After major refactors. Refactoring changes how modules are structured and how they call one another, even when external behavior should stay the same. A full integration run after a significant refactor confirms you did not silently break an interface that no unit test guards.
When adding new integrations. Any time you add or upgrade a third-party service, payment gateway, message queue, or external API, run integration tests against that boundary. New integrations are where contracts are least understood and most likely to surprise you in production.

Integration Testing in the Test Pyramid and SDLC

In the classic test pyramid, integration tests sit in the middle layer — above the broad base of fast unit tests and below the thin tip of slow end-to-end tests. That position is deliberate: there should be many unit tests, a moderate number of integration tests, and relatively few full end-to-end tests. Integration tests are slower and more brittle than unit tests because they touch real collaborators, so you write enough of them to cover critical interfaces without paying the cost of testing every path through the whole system.

Mapped onto the software development lifecycle, integration testing follows component and unit testing and precedes system testing, as captured in the V-model. In an agile flow the boundaries blur — every iteration produces shippable increments — but the ordering still holds within each change: validate units, integrate and validate interactions, then validate the system as a whole. When your integrations span several independent applications or services, that later, broader pass is often called system integration testing. Understanding where this fits is easier alongside the broader stages of the software development life cycle.

Triggering Integration Tests in CI/CD

The most reliable way to answer "when should you run integration testing" is to stop running it by hand. Encode the triggers above into your pipeline so the answer becomes "automatically, on every relevant change." A typical pipeline runs unit tests first as a quick gate, then integration tests, then deploys to a staging environment for end-to-end checks.

# Example CI pipeline stage order (runs on every push / pull request)

# Stage 1 - fast feedback gate
npm run test:unit          # fails the build in seconds on logic errors

# Stage 2 - run integration tests only after unit tests pass
npm run test:integration   # spins up dependencies, checks module interactions

# Stage 3 - deploy to staging, then run system / e2e suites
npm run deploy:staging
npm run test:e2e

# Nightly: a separate scheduled job runs the slow, full integration suite
# that hits real third-party sandboxes and heavy external systems

Split your suite by speed: a fast core integration suite runs on every commit or pull request, while slower runs that exercise expensive external systems run nightly or on a schedule. This keeps developer feedback quick without sacrificing deep coverage. Pair it with solid automation testing practices so the suite stays trustworthy as it grows.

Integration Approaches: Incremental vs Big Bang

How you combine modules also affects when you can start integration testing. There are two broad strategies. With the incremental approach you join and test a few modules at a time, so you can start early and isolate defects quickly. With the big bang approach you wait until everything is built and integrate it all at once, which is simpler to set up but pushes testing late and makes failures hard to localize.

When testing starts: Incremental Integration — early, as soon as two modules are ready; Big Bang Integration — late, only after all modules are built.
Defect isolation: Incremental Integration — easy, failures point to the newly added module; Big Bang Integration — hard, any of the combined modules could be at fault.
Setup effort: Incremental Integration — needs stubs and drivers for missing pieces; Big Bang Integration — minimal scaffolding, single large run.
Best fit: Incremental Integration — CI pipelines and continuous, ongoing development; Big Bang Integration — small projects or systems integrated only once.

Incremental integration itself comes in three flavours, and each one changes what you need in place before testing can begin:

Top-down. Start from the highest-level modules and work downward, using stubs to stand in for the lower modules not yet built. This lets you validate high-level control flow early, so you can begin as soon as the top of the tree is ready.
Bottom-up. Start from the lowest-level modules and work upward, using drivers to simulate the callers above them. Useful when the foundational utilities and data-access layers are finished first.
Sandwich (hybrid). Combine top-down and bottom-up so both ends are exercised in parallel and you meet in the middle. It is the fastest to cover a large system but needs both stubs and drivers.

For most modern, continuously delivered software, an incremental approach is the better fit because it lets you run integration tests early and often — you do not have to wait for every module to be complete, since stubs and drivers fill the gaps. Big bang is generally only acceptable on very small systems. Picking the right helper tooling matters too; see this roundup of integration testing tools, and compare the difference between unit testing and integration testing.

Common Mistakes and Troubleshooting

Running integration tests too late. Saving integration testing for a dedicated phase near release is the classic mistake. Interaction defects compound, and fixing them under deadline pressure is slow and risky. Run them continuously in CI instead.
No isolation between test runs. Shared databases, leftover records, and global state make integration tests flaky and order-dependent. Reset or seed a clean state before each run, or use isolated containers per run, so a pass means something.
Mocking everything. If every collaborator is stubbed, you are really running unit tests in disguise and proving nothing about integration. Keep the boundaries you actually want to verify real.
Skipping tests when external services are slow. Disabling integration tests because a third-party sandbox is slow or unstable hides exactly the failures the test exists to catch. Move slow runs to a nightly job rather than deleting coverage.
Confusing integration with end-to-end testing. End-to-end tests are heavier and validate whole user journeys. Overloading integration tests with full-journey assertions makes them slow and brittle; keep each level focused.

Cross-Environment Integration Testing With Cloud

Integration testing is not only about code talking to code — for web and mobile applications it is also about your integrated front end behaving correctly across the browsers, devices, and operating systems your users run. A flow that integrates cleanly on Chrome for Windows can break on Safari for macOS or a specific Android browser because of rendering, API, or behavioral differences in those environments.

This is where running your integration and end-to-end suites on a cloud grid pays off. With TestMu AI, you can run the same automated suite across 3000+ real browsers and devices, so you validate that your integrated application works everywhere your audience is, not just on the one machine the test was written on. Combine it with cross browser testing and a real device cloud to confirm integrations hold across the full matrix of environments before release.

Conclusion

So, when should you run integration testing? Run it after unit tests pass, continuously in CI on every merge, before system and end-to-end testing, after major refactors, and whenever you add a new integration. The single most important shift is moving integration testing out of a late, manual phase and into your automated pipeline, where defects in how modules interact are caught early, isolated easily, and fixed cheaply. Validate those integrated flows across real browsers and devices, and you can ship with genuine confidence.

Frequently Asked Questions

When in the development cycle should integration testing run?

Integration testing runs after unit tests pass for the modules involved and before system and end-to-end testing. In practice you also run it continuously in CI on every merge, so integration defects surface within minutes of the code change that caused them rather than at the end of a release.

Should integration tests run on every commit or only nightly?

Run a fast core suite on every commit or pull request so contract breaks are caught immediately. Reserve slower, broader integration runs that touch heavy external systems for nightly or scheduled pipelines. This split keeps feedback quick without losing deep coverage of expensive integrations.

Do you run integration tests before or after unit tests?

After. Unit tests verify each module in isolation and are fast, so they run first as a gate. Integration tests then verify that those already-validated modules talk to each other correctly. Running integration tests before unit tests wastes time debugging combined failures that a unit test would have isolated.

When should you run integration tests for third-party APIs?

Run them whenever you add or upgrade an integration with an external service, and on a schedule afterward to catch breaking changes the provider ships. Use contract tests or sandboxes for routine CI runs, and hit the real API in periodic jobs to confirm the live contract still holds.

Is it too late to add integration tests near release?

It is risky but still worthwhile. Defects in how modules interact are far cheaper to fix earlier, so adding integration tests at release time often surfaces issues with little room to fix them. Add them as soon as possible and wire them into CI so future changes are protected continuously.

Can integration testing be done before all modules are complete?

Yes. You do not have to wait for the whole system. Using stubs to stand in for unbuilt lower modules, or drivers to simulate missing callers, you can start integrating and testing as soon as two modules are ready. This incremental approach lets integration run in parallel with development and catches interface defects far earlier.

What is the difference between top-down and bottom-up integration testing?

Top-down starts from the highest-level modules and uses stubs to replace the lower ones not yet built, validating control flow early. Bottom-up starts from the lowest-level modules and uses drivers to simulate the callers above them. A sandwich approach combines both, and all three are incremental, so testing can begin before the full system is assembled.