The Ultimate Guide to Integration Testing: Types, Process, Examples & Best Practices

Integration testing is how teams catch the defects that only appear when separate parts of a system start working together. A module can pass every unit test on its own and still fail the moment it talks to a database, an API, or a third-party service in production. That gap is where most real-world software breaks.

Integration testing on one line: it checks that separately built components work together correctly once combined. It runs after unit testing and before system testing, and in modern CI/CD it runs continuously. 

Why it is worth your attention: 

• Poor software quality cost the US an estimated $2.41 trillion in 2022, with about $1.52 trillion of that sitting in accumulated technical debt. 
• A defect caught after release costs up to 30 times more to fix than one caught early in development.  

This guide covers what integration testing is, when to run it, the types and strategies you can choose from, real examples, tools, how it fits into CI/CD, how it applies to AI systems, and the practices that separate teams who ship with confidence from teams who ship and wait for the pager to go off.

What is Integration Testing?

The ISTQB defines integration testing as a test level that focuses on the interactions between components or systems. In practice, that means combining individual units or modules and testing them as a group, so the focus shifts from whether each part works to whether the parts work together. 

Where It Fits in the SDLC

Modules Testing vs. Integration Testing

The difference between module (unit) testing and integration testing is subtle but critical: 

• A unit test confirms that a calculateInterest() function returns the right number for a given input. 
• An integration test confirms that the same function succeeds when it must pull a rate from a live service, write the result to a database, and pass it to a statement generator.  

Why Integration Testing Matters

Even when individual modules pass unit testing perfectly, failures often occur when they interact. Because most real defects don’t live inside any single component. 

That is the gap integration testing exists to close. 

• It catches interface failures between modules, APIs, databases, and third-party services. These are the breaks that pass every unit test and only surface once real traffic hits them. 
• It detects integration defects early, drastically reducing the cost and effort of fixing bugs. 
• It improves overall software reliability and system stability as the application scales. 
• It supports CI/CD by automatically validating integrations before every release, making continuous delivery safe. 
• Fewer production incidents. That means less firefighting, fewer 2am pages, and a user experience that does not wobble every release. 

When Should Integration Testing Be Performed?

Integration testing should be performed whenever changes could affect how application components communicate with each other. To maximise value, perform these tests at the following points in the SDLC: 

• After unit testing to confirm that modules which passed on their own actually cooperate.
• Before system testing, so the integrated build is stable before you validate the full application.
• After API updates, to check that requests, responses, authentication, and data exchange still behave.
• After database changes such as schema updates, migrations, or stored procedure edits that ripple into connected services.
• Inside CI/CD pipelines, so every commit or build automatically re-validates integrations and catches regressions the moment they appear.
• Before production releases, to lower deployment risk and keep integration defects from reaching users.

Integration Testing Process

Two of those stages deserve their own gates. Entry and exit criteria decide when integration testing starts and when it is genuinely finished, and writing them down keeps the whole effort honest.

Entry criteria	Exit criteria
Unit testing complete for all modules	All planned integration cases executed
Test environment provisioned and stable	Critical and high-severity defects resolved
Test data finalized (valid, invalid, edge)	Integration paths regression-clean
Test plans reviewed and approved	Coverage thresholds met
Required APIs and external services reachable	Sign-off recorded

Types of Integration Testing

Beyond these four, most teams building on microservices now lean on a modern set of approaches. 

• Contract testing, using a tool like Pact, checks that a service and its consumers agree on the shape of requests and responses without needing every dependent service running.
• Consumer-driven contracts take that further by letting the consumer define what the provider must satisfy. 
• Service virtualization stands in for dependencies that are slow, costly, or owned by another team. 

These methods do not replace classic testing strategies. Instead, they make integration testing feasible when you have more services than you can realistically spin up at once.  

Integration Testing Strategies Compared

Strategy	Starts from	Advantages	Disadvantages	Best for
Big Bang	All modules at once	Minimal planning	Hard to isolate defects	Small systems
Top-Down	High-level modules	Early core-flow validation	Needs many stubs	UI-led designs
Bottom-Up	Low-level modules	Strong foundation testing	Late high-level validation	Data-heavy systems
Sandwich	Middle layer	Balances both directions	Complex to plan	Layered enterprise apps

Integration Testing Examples

• Banking payment flow. Ensuring account services, ledgers, fraud checks, and gateway sync perfectly to prevent double-posted transactions. 
• E-commerce checkout. Validating the cart, inventory, tax service, and payment gateway lines up to prevent mismatched totals. 
• Healthcare appointment booking. Keeping EHR systems, scheduling, and notifications in sync across different providers. 
• CRM + Email platform. Testing handoffs to prevent silent sync drops or duplicated lead records. 
• ERP integrations. Preventing data formatting and mapping errors between HR, finance, and attendance systems. 
• Payment gateway callbacks. Ensuring authorisation, capture and settlement callbacks agree on state. 

For teams in banking, finance, and government, the money and the compliance risk live in the handoffs, not the individual services. 

API Integration Testing

APIs are where most integration defects live, because APIs are where most systems connect. 

• API integration testing covers REST, GraphQL, gRPC, and asynchronous APIs, and the checklist is consistent across all of them.
• You validate authentication and authorization, so a request that should be rejected actually is. 
• You check status codes, because a 200 wrapping an error body is its own kind of lie. You validate the request, confirming the API rejects malformed input instead of quietly accepting it. 
• You validate the response, confirming the payload matches the agreed schema. 
• You test pagination and error handling, the parts that only break under real data volumes.

This is also where contract testing pays off. Instead of standing up every dependent service to test one API, contract testing verifies that a request and response match the agreed schema between consumer and provider in isolation. It lets a team validate its side of an integration without waiting on everyone else’s.

Database Integration Testing

• CRUD validation: Checking Create, Read, Update, and Delete operations against real database connections rather than just mocks.  
• Transactions: Ensuring failures mid-process leave data consistent rather than half-written.  
• Data consistency: Confirming data stays synced and correct across shared services.  
• Rollbacks: Verifying that rollbacks actually reverse failed transactions.  
• Foreign keys: Testing relationship integrity across tables.  
• Data migration: Validating that schema changes and migrations do not corrupt data flows

Integration Testing in CI/CD

Integrating these tests into the pipeline turns testing from a phase into a continuous habit. 

Tools: GitHub Actions, GitLab CI, and Azure DevOps are heavily utilized to automate these checks. 

Tests should run on nightly builds, on every Pull Request and throughout the continuous integration cycle.

Integration tests act as gates, automatically blocking merges and deployment if interaction fails. 

For anyone measuring release velocity, this is the part that matters. Ephemeral environments and pipeline-gated integration tests let a team move quickly without the usual trade-off of moving quickly and breaking things. 

Integration Testing for AI Applications

AI systems have added a whole new integration surface, and most older testing guides do not cover it. If your product touches an LLM, a retrieval pipeline, or an agent, your testing scope must expand. 

New Integration Points to Validate:

• Model APIs and prompt orchestration workflows.
• RAG pipelines and vector database retrievals. 
• Multi-step agent tool-calling and MCP (Model Context Protocol) servers.
• Session memory and guardrail systems. 

The 2026 Reality: Testing AI-Generated Code

AI generated code goes live faster than teams review it. And it can look perfectly correct while quietly breaking an API contract or changing a data format. That makes it harder to catch by eye, so it needs the same integration validation as human-written code. 

Kualitatem already handles both AI and agentic systems testing. The approach does not change: the handoff is where things break, so that is where we start. 

Manual vs Automated Integration Testing

Dimension	Manual integration testing	Automated integration testing
Speed	Slower, human-paced	Fast, runs on every commit
Cost	Lower upfront, higher ongoing	Higher upfront, lower per run
Accuracy	Prone to human error on repetition	Consistent and repeatable
Scalability	Limited by team size	Scales across builds and services
Maintenance	Low tooling upkeep, high effort per run	Scripts need upkeep as APIs change
Best for	Exploratory, first-time, complex flows	Regression, CI/CD, high-frequency paths

Integration Testing vs Other Testing Types

Integration testing is one level in a wider stack. It sits alongside unit, system, functional, and regression testing, each with a different focus and timing. 

Testing type	Focus	When it runs
Unit	One function or module in isolation	During development
Integration	Interfaces between combined modules	After unit, before system
System	Complete application vs requirements	After integration
End-to-End	Full user journey across the stack	Late, pre-release
Functional	Features behave to spec	Throughout
Regression	Existing features after a change	After any change

Best Tools for Integration Testing

Tool	Best for
Postman	REST and SOAP API testing
SoapUI	SOAP and API contract testing
REST Assured	Java API integration tests
Pact	Contract and consumer-driven contract testing
Selenium	Web UI integration paths
Cypress	Modern web app integration
Testcontainers	Running tests against real dependencies
WireMock / MockServer	Mocking and service virtualization
TestNG / JUnit / PyTest	Test frameworks for Java and Python
Docker Compose	Spinning up test environments
Jenkins / GitHub Actions / GitLab CI	Running integration suites in CI/CD

Common Challenges

• Testing one path often drags in many others.
• External SaaS tools update or deprecate on their own schedules.
• Keeping data realistic and consistent across environments is difficult.
• Shared staging environments often become bottlenecks or act flaky.
• A high volume of microservices multiplies the total connections to test.
• Desynced component versions can slip through without strict contracts.
• Virtualised services can drift out of sync with real APIs.
• Tests that fail without a code change due to timings or shared data. 

Integration Testing Best Practices

The teams that ship confidently tend to do the same handful of things.

• Shift-left testing, so integration issues surface during development instead of before release.
• Automate the repetitive tests and run them on every merge.
• Use realistic test data. The three tidy happy-path records that always pass are how bugs sail through testing and land on a customer. 
• Test APIs separately, so a broken interface is obvious before it hides inside a larger flow.
• Use mocks and stubs for dependencies that are missing, slow, or unreliable.
• Keep environments consistent, ideally reproducible through infrastructure as code.
• Prioritize the high-risk integrations first. A payment path and a settings screen are not the same. So do not test them like they are. 
• Integrate testing into CI/CD so it runs automatically, not when someone remembers.
• Monitor failed integrations in production, because some problems only appear under real load.
• Review test coverage regularly, so gaps do not quietly widen as the system grows.
• Practice contract-first development, validating the API agreement before the implementation exists.

Common Mistakes to Avoid

• Skipping integration tests entirely and trusting that good units make a good system. They do not.
• Testing only happy paths, so the first unusual input in production becomes an incident.
• Ignoring edge cases, which is where integration defects concentrate.
• Using poor or unrealistic test data that passes tests and fails users.
• Not testing third-party APIs, then getting surprised when a vendor changes something.
• Running no automation, so integration testing becomes a bottleneck nobody wants to own.
• Sharing one unstable environment, which turns flaky tests into a daily tax.
• Missing negative testing, so you never confirm the system fails safely when it should fail.

Frequently Asked Questions (FAQs)

1. What is integration testing? 

Integration testing evaluates how separate components behave when combined. Its primary goals are to:

• Validate the interactions between modules, APIs, databases, and third-party services. 
• Verify functionality to ensure parts that pass isolated unit tests still work correctly together. 
• Check the handoffs rather than the internal logic of any single component. 

2. Why is integration testing important? 

Components can pass unit tests perfectly but still fail when interacting because most real defects live in the handoffs. It is critical because it:

• Resolves interface bugs before they reach production, when they are significantly cheaper to fix. 
• It lessens the financial risk. 

3. What are the different types of integration testing? 

The four classic types are: 

1. Big Bang
2. Top-Down 
3. Bottom-U
4. Sandwich (Hybrid). 

4. What is the difference between integration and system testing? 

Integration testing checks the connections between combined modules and runs after unit testing. System testing validates the complete, integrated application against business requirements and runs after integration testing. One checks the wiring, the other checks the finished product.

5. What tools are used for integration testing? 

The right mix depends entirely on your stack, but common tools include: 

• APIs: Postman and SoapUI.  
• Contract Testing: Pact.  
• Web Paths: Selenium and Cypress.  
• Mocking: WireMock and MockServer.  
• Real Dependencies: Testcontainers.  
• CI/CD Runners: Jenkins, GitHub Actions, or GitLab CI.

6. Can integration testing be automated? 

Yes, and most integration testing in modern pipelines is automated. Automation handles the repetitive, high-frequency checks that run on every commit. Manual and exploratory testing still covers complex, first-time, or judgment-heavy integration paths where a human catches what a script would miss.

7. When should integration testing be performed? 

Run it after unit testing, before system testing, after API or database changes, on every commit inside CI/CD, and before every production release. The underlying rule is to test integrations whenever a change could affect how components communicate.

8. How is contract testing different from integration testing?

Contract testing checks that a request and response match an agreed schema between a consumer and provider in isolation, without running every dependent service. Integration testing verifies actual runtime behaviour when components interact together. Contract testing is faster and narrower; integration testing is broader and closer to real conditions.

9. Should AI-generated code go through integration testing?

Yes. AI-generated code can look correct while quietly changing API behaviour, data formats, or error handling. It should go through the same integration validation as human-written code, and arguably stricter, because its failure modes are harder to catch by reading.

10. What are flaky integration tests and how do you fix them?

Flaky tests pass and fail inconsistently without any code change, usually because of timing issues, shared test data, or unreliable external dependencies. You fix them by isolating test data, controlling for timing, and using mocks or service virtualization so a test does not depend on another service being up.

TL’DR

Software rarely fails inside a single component. It fails at the connections, which is exactly what unit testing leaves unchecked. That is why integration testing is essential, and why in Agile and DevOps teams it has to run inside the pipeline on every commit.

The right approach depends on your stack: incremental for most work, contract testing and virtualization once you are on microservices. The strongest teams pair automated checks in CI/CD with manual testing on the complex, high-risk paths.

Kualitatem’s engineers validate every integration point across your modules, APIs, and third-party systems before your users see the release. Speak to an Expert →