Modules that pass unit tests are no proof that the whole system works. The failures hide exactly at the interfaces: wrong data formats, unexpected status codes, brittle contracts between services. Integration testing exposes those gaps before they reach production. For organisations running many independently deployed microservices—banks especially—it decides stability and auditability. This guide walks you through the four integration strategies, the clean distinction between stub, driver and mock, and modern contract testing with Pact. You'll also see how to wire integration tests into a concrete CI/CD pipeline and keep them stable with self-healing.

In brief: Integration testing checks the interaction and interfaces between integrated components. In the test pyramid it sits between component and system tests. With 74% of organisations now API-first (Postman, 2024), contract testing with Pact has become key for independently deployable microservices.

Figure 1: Integration testing sits between component and system tests.

What is integration testing?

Integration testing aims to expose defects in the interfaces and in the interaction between integrated components, per the ISTQB definition (ISTQB Glossary, 2024). It checks communication, not individual building blocks. That's precisely where systems fail: in data hand-offs, call sequences and contract boundaries between modules.

Two levels matter. Component integration testing checks the interaction between components within a system and usually sits with the development team—right after unit testing. System integration testing checks the interaction between systems, packages, microservices and external interfaces.

So why isn't a unit test enough? Because a module can be correct in isolation yet still fail to talk to its neighbour. Interface defects are relationship defects—they exist only in the interaction. Integration testing turns that interaction into the thing under test.

For broader context, see our overview of software testing types.

Where does integration testing sit in the test pyramid?

Integration testing sits between component tests (the base) and system or end-to-end tests (the top) of the pyramid (Martin Fowler, 2018). The model traces back to Mike Cohn. The logic is simple: many fast unit tests below, fewer but broader tests above.

This position has practical consequences. Integration tests run slower than unit tests because they wire in real dependencies—databases, queues, neighbouring services. Yet they run faster and more precisely than full end-to-end tests that drive the whole system through its surface.

A common anti-pattern: teams paper over missing integration tests with ever more E2E tests. The result is slow, brittle suites. A deliberate split works better—interfaces tested integratively, business flows end-to-end.

We explore the top of the pyramid in our piece on end-to-end testing.

What integration strategies are there?

Figure 3: The four integration strategies at a glance.

Four strategies dominate practice: big-bang, top-down, bottom-up and sandwich. They differ in the order modules are merged and which aids—stubs or drivers—make that possible (Qytera, 2026). Your choice decides how early you get meaningful feedback.

In our experience, enterprise teams rarely pick pure big-bang. The approach saves effort upfront but pays it back double once a defect appears and nobody knows which of the simultaneously integrated interfaces caused it. Top-down and bottom-up give isolatable feedback; sandwich combines both for complex architectures.

Stub, driver or mock—what's the difference?

These three terms get confused constantly, yet they name clearly separate tools—all defined in the ISTQB glossary (GTB Glossary, 2024). The difference lies in call direction and test goal. Know it, and you build cleaner tests.

A quick rule of thumb: a stub sits below and answers, a driver sits above and calls. A mock goes further—it checks not just returns but whether and how it was called. Mocks therefore serve behaviour verification, stubs serve plain state responses.

How does integration testing work for APIs and microservices?

Figure 2: 74% of organisations work API-first (Postman, 2024).

In distributed systems, integration testing verifies interaction over HTTP, REST, gRPC or messaging via Kafka and RabbitMQ. The focus is schemas, status codes, authentication, error handling and contracts. This is core business now: 74% of organisations are API-first in 2024, up from 66% the year before (Postman, 2024).

APIs have long been a business model, not just plumbing. 62% of companies generate revenue directly from APIs (Postman, 2024). The pace is rising too: 63% of developers can ship an API within a week, up from 47% (Postman, 2024).

Faster delivery across more interfaces means more places where contracts can break. For practice, we recommend:

• Containerise dependencies (Docker, Testcontainers) instead of shared test environments

• Automate contract and schema checks rather than sampling manually

• Cover error paths and auth edge cases explicitly, not just the happy path

What is contract testing with Pact—and why do banks need it?

Contract testing verifies whether the consumer and provider of an API contract match—without spinning up a full end-to-end environment. The approach is consumer-driven: the consumer defines its expectation, the provider verifies it against a versioned contract (Pact, 2024). The go-to tool is Pact, paired with the Pact Broker.

The benefit is concrete. Not everything needs a full integration test—contract tests check the interface precisely, fast and in isolation (Microsoft ISE, 2024). For banks with many independently deployed microservices this is decisive: teams deploy separately without a central stage becoming the bottleneck.

In regulated environments, traceability counts. Versioned contracts in the broker document which service version is compatible with which—an auditable trail. That cuts the risk of an independently rolled-out service silently breaking a contract partner. Contract tests run at developer level and complement system integration tests; they don't replace them.

How do you wire integration tests into CI/CD?

Figure 4: Wiring integration tests into CI/CD in three steps.

Integration tests prove their worth once automated in the pipeline—run in Jenkins, GitHub Actions or GitLab CI on every relevant commit. The payoff is concrete: roughly 45% of teams automate their regression tests, making it the most-automated discipline, while 82% still test partly by hand (Katalon, 2025). There's untapped potential here.

A reliable workflow follows a clear pattern:

1. Provision dependencies—spin up databases, queues and neighbouring services ephemerally via Testcontainers, isolated per run.

2. Run tests against real interfaces—not against shared mocks, but against containerised real components.

3. Set gating—if an integration or contract test fails, block the merge. No red build reaches the main branch.

One familiar problem remains: UI-driven system integration tests break the moment interfaces or selectors change. This is where self-healing locators help—they detect shifted elements and adapt instead of failing red. Autemos covers web, mobile, API and desktop tests with self-healing and a visual recorder, keeping system integration tests stable when interfaces drift—complementary to developer-level contract tests.

Read how self-healing locators work technically here.

Is the effort worth it? What do uncaught defects cost?

Defects get more expensive the later you find them—that's the solid, evergreen point behind integration testing. Academic work supports the direction: a defect found in integration costs on average around 4.55 staff-hours, one in the system phase about 6.2 (Wagner, arXiv, 2016). Catch earlier, catch cheaper.

Be wary of the widely cited order-of-magnitude tables. The popular 1×/10×/100× ladders cannot be traced credibly, so we deliberately avoid them here. The direction of the claim—cost rises with the detection phase—is sound; the specific multipliers are not.

For practice, that direction is enough. An integration test that stops an interface break in the CI run is cheaper than the same defect in the system test, in acceptance, or—most expensive of all—in production.

FAQ

What is the difference between integration testing and system testing?

Integration testing checks the interaction and interfaces between integrated components or systems. System testing checks the complete, integrated system against requirements. In the test pyramid, integration sits below it (Martin Fowler, 2018). In short: integration checks connections, system checks the whole.

Stub or mock—which do I use when?

Use a stub when you only need predefined responses from a called module, for instance in top-down integration. Use a mock when you want to verify whether and how a dependency was called—the behaviour (GTB Glossary, 2024). A stub checks state, a mock checks interaction.

Does contract testing replace integration testing?

No. Contract testing targets the contract between consumer and provider without a full environment—fast and isolated (Microsoft ISE, 2024). It complements system integration tests rather than replacing them. Together they give microservice teams confidence to deploy independently.

Which strategy suits microservices?

With many independently deployed services, pure big-bang is risky because defects stay hard to isolate. The proven combination pairs bottom-up integration of base services with consumer-driven contract testing. That keeps base services stable early (Qytera, 2026), while contracts protect the interfaces.

How do I automate integration tests in the pipeline?

Provision dependencies ephemerally via Testcontainers, run tests against real interfaces, and set gating that blocks faulty builds. So far only around 45% of teams automate their regression tests consistently (Katalon, 2025). More on strategy in our guide to AI test automation.

Conclusion

Integration testing is the underrated middle of the test pyramid—the layer that decides whether modules that look clean in isolation also hold together in concert. Know the four strategies, separate stub, driver and mock cleanly, and take contract testing with Pact seriously, and you gain confidence exactly where distributed systems break most often: at the interfaces. With 74% of organisations now API-first, this is no longer a niche concern (Postman, 2024). For banks, the auditability of versioned contracts adds further weight. Automate integration tests in CI/CD, keep UI-near checks stable with self-healing, and stop interface breaks before they get expensive. Talk to our team about automating your integration tests reliably.