Components that work well on their own don't always work well when integrated with each other. That's why integration testing is essential in your testing project.
In this article, I'll show you:
Let's dive in!
Integration testing is a type of testing in which multiple parts of a software system are gradually integrated and then tested as a group.
The goal of integration testing is to check whether different software components work seamlessly with each other.
Let's say that you are testing a software system with 10 different modules.
Each of these modules has been unit tested. They all pass, meaning they work well individually. That's a good sign. However, can we be sure that those individual parts will work smoothly together?
Conflicts can always arise โ just like how people who work well individually may not always work well as a team.
Once these modules are integrated, things can go wrong in several ways, such as:
That's why testers must perform integration testing to uncover those scenarios. Out of the 10 modules, testers can first choose two modules to integrate. If these modules interact smoothly, they proceed with another pair, and so on, until all modules are tested.
There are 2 common approaches to integration testing:
Big Bang Integration testing is an approach in which all modules are integrated and tested at once as a single combined system.
Big Bang integration testing is not performed until all components have successfully passed unit testing.
Advantages of Big Bang integration testing:
Disadvantages of Big Bang integration testing:
Best Practices when using Big Bang testing:
๐ Read More: Big Bang Integration Testing: A Complete Guide
Incremental integration testing is an approach in which 2 or more modules with closely related logic are grouped and tested first, then gradually expanded to other modules until the entire system is integrated and tested.
It is more strategic than Big Bang testing because it requires detailed planning in advance.
Advantages:
Disadvantages:
You can further divide incremental integration testing into 3 approaches:
The distinction between low-level and high-level components depends on their position in the system hierarchy:
If you apply this to an eCommerce website, the breakdown looks like this:
| 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 |
|
|
With bottom-up integration testing, you start integrating modules at the lowest level, then gradually move to higher-level modules.
As shown in the diagram, the lower-level components represent specific items such as shirts and polos. These fall under the โTopsโ category, which belongs to โMenโs clothingโ, and ultimately โClothingโ.
With the bottom-up approach, you test from the most specific components toward the more generic, comprehensive modules.
Use bottom-up integration testing when:
๐ Read More: Bottom-up Integration Testing: A Complete Guide
With top-down integration testing, testers start with the highest-level modules and move downward toward lower-level modules.
Use top-down integration testing when:
๐ Read More: Top-down Integration Testing: A Complete Guide
Hybrid Integration Testing (also known as Sandwich Testing) combines both top-down and bottom-up approaches, running them in parallel.
Advantages:
Disadvantages:
If you ever wanted to create a test strategy, the test pyramid is a great framework to follow.
The Test Pyramid is a widely used model that illustrates how different types of tests should be distributed within a testing strategy. The idea is to automate the bulk of tests at the lower layers (unit and integration tests) while keeping the more expensive end-to-end tests to a minimum.
The three layers of the test pyramid include:
If you follow the Test Pyramid strategy, a common ratio is roughly: 70โ80% unit tests, 15โ20% integration tests, and 5โ10% end-to-end (E2E) tests.
The rationale is that:
Although these ratios serve as a helpful guideline, you should adjust them based on your team size, system complexity, and available resources.
Put simply:
The scope of end-to-end testing is bigger than that of integration testing.
Here is a simple comparison table of the differences between integration testing and end-to-end testing:
| End-to-End Testing | Integration Testing | |
| Purpose | Checks system behavior in real-world scenarios | Checks integration between components |
| Scope | Broader in scope and covers the entire technology stack | Focuses on interactions between components/modules |
| Testing stage | Performed at the end of the development lifecycle before releases | Executed 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 |
๐ Read More: End-to-end testing vs Integration Testing
| 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 works as intended in isolation. | Verifies that different units or modules work together correctly. |
| Dependencies | Mocks or stubs external dependencies to isolate the unit. | Uses real dependencies to test actual integration behavior. |
| Granularity | Tests small, specific pieces of functionality. | Tests how multiple units collaborate. |
| Execution Environment | Runs easily in a development or CI environment. | Requires an environment where modules can run together. |
| Test Data | Uses small datasets or mocked data. | Often uses more realistic datasets for interaction testing. |
๐ Read More: Unit Testing vs Integration Testing: In-depth Comparison
The Katalon Platform is an all-in-one solution for teams to plan, design, and manage test cases in a single place. It supports a wide range of application types, including API testing and UI Testing to cover all your quality needs.
UI testing is challenging due to the huge number of devices and browsers in use today. A layout may be perfect on one device but break completely on another. Katalon helps teams stay on budget with cloud-based cross-platform and cross-browser execution support.
Katalon is designed to simplify test maintenance. When an application changes, testers must confirm whether existing scripts still work. With its page-object design model and centralized object repository, Katalon makes updates far easier.
By storing locators and artifacts in one place, teams can quickly adjust tests when UI elements or flows change.