What can possibly happen when those smoothly-running software modules are integrated together? Well, they either work or they break. Things that run well individually can totally break when merged. That's exactly why we need integration testing.

What is Integration Testing?

Integration testing between two modules
Integration testing, also known as integration and testing (I&T), is a type of software testing where various units, modules, or components of a software application are tested together as a unified system.

The basis of integration testing is the idea that individual software modules may break when combined together. Testers merge modules that have been unit tested to check their interaction. Integration testing examines interfaces, communication protocols, and data flows between those modules.

Think of integration testing as fine-tuning an orchestra. Each instrument (individual software modules) needs to play its notes correctly, but even more importantly, they need to harmonize with other instruments (other software modules). The goal is to avoid that terrible moment where the trumpet blasts off-key or the drums come in late.

Integration Testing Example

A good example of integration testing is the interaction between the checkout module and payment gateway on an e-commerce platform.

Before beginning integration testing, ensure each component works well on its own through unit testing. Once these individual validations are complete, you can proceed with integration testing. Here are some example test cases:

Ensure items, quantities, prices, and discounts transfer correctly from cart to checkout.
Confirm billing and shipping info populates accurately for logged-in users, and new user info saves properly.
Verify checkout redirects to the correct payment gateway with secure order amount and ID.
For successful payments, display a “Payment Successful” message; for failures, show retry prompts.
Confirm order confirmation message and email include items, order ID, and shipping details.
Ensure inventory updates in real-time after order confirmation to reflect items sold.
Check payment status (e.g., “Pending,” “Completed”) updates correctly on user order history.

These test cases help ensure that the checkout and payment modules work seamlessly together, creating a reliable and smooth experience for users.

Why is Integration Testing Important?

Software is often built from many individual software components or modules. Issues between those modules can always happen for many reasons:

Inconsistent code logic: They are coded by different programmers whose logic and approach to development differ from each other, so when integrated, the modules cause functional or usability issues. Integration testing ensures that the code behind these components is aligned, resulting in a working application.
Shifting requirements: Clients change their requirements frequently. Modifying the code of 1 module to adapt to new requirements sometimes means changing its code logic entirely, which affects the entire application. These changes are not always reflected in unit testing, hence the need for integration testing to uncover the missing defects.
Erroneous Data: Data can change when transferred across modules. If not properly formatted when transferring, the data can’t be read and processed, resulting in bugs. Integration testing is required to pinpoint where the issue lies for troubleshooting.
Third-party services and API integrations: Since data can change when transferred, API and third-party services may receive false input and generate false responses. Integration testing ensures that these integrations can communicate well with each other.
Inadequate exception handling: Developers usually account for exceptions in their code, but sometimes they can’t fully see all of the exception scenarios until the modules are pieced together. Integration testing allows them to recognize those missing exception scenarios and make revisions.
External hardware interfaces: Bugs can also arise when there is software-hardware incompatibility, which can easily be found with proper integration testing.

All of these scenarios can be prevented with good integration testing processes in place.

Integration Testing vs End-to-end Testing

Simply put, integration testing verifies interactions between individual components or modules, whereas end-to-end testing verifies the flow of an entire user journey. The scope of end-to-end testing is bigger than that of integration testing.

	End-to-End Testing	Integration Testing
Purpose	Validates system behavior in real-world scenarios	Validates integration between components
Scope	Broader in scope and covers the entire technology stack of the application	Interaction between different components/modules
Cost	More expensive as it often requires more resources, including personnel, equipment, and testing environments.	Less expensive than end-to-end testing
Testing stage	Performed at the end of the software development lifecycle before releases	After unit testing and before end-to-end testing
Technique	Black-box testing, often uses User Acceptance Testing (UAT)	White-box testing, often uses API testing

Unit Testing vs Integration Testing: Key Differences

In simple terms, unit testing focuses on testing individual units in isolation, while integration testing is about putting those units together to test as a whole. There are also several differences between them in other aspects, such as purpose, dependencies, and execution environment. You have a look at the table below to see the comparison between the two testing types:

Aspect	Unit Testing	Integration Testing
Scope	Focuses on testing individual units of code (functions or methods).	Focuses on testing interactions between multiple units or modules.
Purpose	Verifies that each unit of code works as intended in isolation.	Verifies that different units or modules work together correctly.
Dependencies	Mocks or stubs external dependencies to isolate the unit being tested.	Uses real dependencies, as it tests the integration between units.
Granularity	Tests specific functionality within a small code unit.	Tests how different units collaborate with each other.
Execution Environment	Can be executed in a development environment or Continuous Integration (CI) system.	Requires a more elaborate environment to host multiple units working together.
Test Data	Typically uses small datasets or mocked data to isolate the unit.	May use larger datasets to mimic real-world scenarios for interactions.
Test Speed	Generally faster as it focuses on smaller pieces of code.	Can be slower due to the need to set up and tear down multiple units.
Bug Identification	Helps to identify and isolate bugs within individual code units.	Helps to identify bugs related to how units interact with each other.
Test Coverage	Provides higher coverage for individual units or functions.	Provides higher coverage for the interactions between units.
Test Maintenance	Requires updates only when the unit's behavior changes.	May need updates when the interaction between units changes.
Deployment	Can be run as part of a developer's workflow.	Typically conducted after unit tests and before end-to-end tests as part of integration pipelines.
Importance in CI/CD	Essential for Continuous Integration (CI) to ensure small units work as expected.	Critical for Continuous Deployment (CD) to ensure all parts work together.

Types Of Integration Testing

There are several strategies to perform integration testing, each of which has its own advantages and disadvantages, with the 2 most common approaches being:

Big Bang approach
Incremental approach

1. Big Bang Integration Testing

Big Bang Integration testing is an integration testing approach in which all modules are integrated and tested at once, as a singular entity, hence the name “Big Bang”. This approach only carried out when all components have been successfully unit tested.

Advantages:

Suitable for simple and small-sized systems with low level of dependency among software components
Little to no planning beforehand required
Easy to set up since all modules are integrated simultaneously
Management and coordination efforts are minimized since there is only one major testing phase

Disadvantages:

Costly and time-consuming for large systems with a huge number of units as testers have to wait until all modules have been developed to start testing
Waiting for all modules to be developed before testing also means late defect detection
Hard to isolate and pinpoint bugs in specific modules
Hard to debug due to the complexity of multiple integrated modules

Best Practices when using Big Bang testing:

Clearly define the interactions between each unit/function before testing to minimize missing defects
Perform extensive logging for more accurate fault localization
Perform Big Bang testing for simple applications

2. Incremental Integration Testing

Incremental integration testing is an approach in which two or more modules with closely related logic and functionality are grouped and tested first, then gradually move on to other groups of modules, instead of testing everything at once. The process ends when all modules have been integrated and tested.

Incremental integration testing is more strategic than Big Bang testing. It requires substantial planning beforehand.

Advantages:

Defects are found sooner, as modules are integrated and tested as they’re developed, unlike Big Bang testing, where testing waits until all modules are complete.
Testing smaller module groups makes it easier to pinpoint issues.
QA managers can prioritize modules based on urgency, priority, or resources.
Early issue detection helps prevent serious failures later on.

Disadvantages:

Mock components may be needed early on if certain functionalities aren’t ready.
Large projects require substantial resources due to the number of tests.
Managing a large integration testing project can be challenging.
The system’s structure and logic must be fully defined to break it into testable units.
Missing or incomplete functionalities early on could lead to overlooked areas if not well-documented.

Approaches of Incremental Integration Testing

Incremental integration testing can be divided into three approaches, each with its own pros and cons that QA teams should consider. These approaches are named based on how much impact the components being tested have on the overall system:

Bottom-up approach: Start testing with low-level components and gradually move up to higher-level ones.
Top-down approach: Start testing with high-level components and gradually move down to lower-level ones.
Hybrid approach: Combine both the bottom-up and top-down methods.

To understand these approaches, it's important to define low-level and high-level components:

Low-level components are the basic building blocks of software, performing simple, specific tasks with minimal impact on the overall system, like basic data structures or functions.
High-level components are complex and represent the system's core behaviors, handling tasks such as data processing, management, or security. Bugs in high-level modules can threaten the entire system.

The table below provides a comparison and examples of these component types in an eCommerce website context:

Aspect	Low-Level Modules	High-Level Modules
Complexity	Simple functionalities	Complex, multi-functional
Scope	Focused on specific tasks	Comprehensive functionalities
Granularity	Smaller and modular	Larger and more integrated
Examples	Input validation module Database connection HTTP request handling Product data processing Basic data structures	User management module Product catalog module Shopping cart & checkout Payment processing Order processing

1. Bottom-up Approach For Incremental Integration Testing

With the bottom-up approach, testers start with individual modules at the lowest level, then gradually move to higher-level modules, hence the term “bottom-up”. The rationale for this approach is that the entire system can only work reliably if these basic building blocks work reliably.

Let's use an analogy to understand the concept better.

A “bottom-up” approach is essentially going from the more specific and granular components to more general and comprehensive components.

Integration testing bottom-up approach

Imagine software components as types of clothing.

The lower level components are shirts and polo (specific types of clothes). Shirts and polos fall under the “Tops” category, which falls under the “Men's clothing” category. At the highest and most generic level, they are simply called “clothing”.

When using the bottom-up approach for integration testing, we go from the specific modules to more comprehensive modules, or from the “shirt” module to the “clothing” module.

Bottom-up integration testing is best used when:

Complexity is mostly in lower-level modules
Development starts with lower-level components before moving to higher levels
Precise defect isolation is important
Higher-level modules are still being developed or change often

2. Top-down Approach For Incremental Integration Testing

With the top-down approach, testers start with the highest-level modules, then gradually move to lower-level modules, hence the term “top-down”.

Integration testing top-down approach

For example, the diagram above illustrates the modules required for a ride-hailing application:

Module A: User Authentication
Module B: Ride Booking
Stub DI: Driver Information
Module P: Payment Processing
Module PC: Payment-by-cash/ PC
Stub DP: Debit Card/Credit Card Payment aka DP (Yet to be developed)
Stub EP: E-Payment/ EP (Yet to be developed)
Module T: Ride Tracking

Both approaches share the general pros and cons of incremental integration testing. The main difference is in the situations where each is most effective, with the choice depending on the project’s specifics, development style, and testing needs.

Top-down integration testing is useful when:

Key functions are mainly in high-level components
Real-world scenarios and user interactions need to be simulated early for a full view of system behavior
Lower-level modules are stable and unlikely to change
User-facing features require quick validation, allowing for early prototypes and feedback

In bottom-up testing, stubs may be needed to replace high-level modules not yet built. In top-down testing, drivers can stand in for missing low-level modules. Stubs and drivers act as simplified versions of real components, enabling testing to proceed without waiting for all parts to be completed.

3. Hybrid Approach For Incremental Integration Testing

Sandwich Testing (also known as Hybrid Integration Testing) is an approach in which testers employ both top-down and bottom-up testing simultaneously.

Advantages:

QA teams can tailor their integration testing activities based on project requirements, combining the strengths of different methods.
More flexibility in terms of using resources
Ensuring that both the low-level and high-level software components are verified at the same time

Disadvantages:

Complex and requires careful planning and coordination to decide which modules to test using each method
Effective communication among team members is crucial to ensure consistency and proper tracking of issues
Teams may find it challenging to switch between different integration strategies

Integration Testing Best Practices

To create a well-rounded integration testing strategy, testers should work closely with developers and clients to align on the project vision and adjust the approach as needed. Following best practices will ensure thorough and effective integration testing:

Ensure all modules have passed unit testing before starting integration tests for reliable results.
Develop a plan outlining the scope, objectives, test cases, and required resources for integration testing.
Automate repetitive and complex test cases to improve efficiency and maintain consistency across test runs.
Verify that input test data is accurate and reliable to enhance test quality.
Perform regression tests after each integration to confirm new changes do not adversely affect previously integrated components.

How To Automate Integration Testing

Katalon logo

The Katalon Platform is a powerful All-in-One platform to help QA teams plan and design test cases in 1 place without having to use any additional tools. Katalon also supports a wide range of application types, including API Testing and UI Testing to cover all of your needs.

Start Integration Testing With Katalon Free Trial