Integration testing is a type of software testing where components of the software are gradually integrated and then tested as a whole. Usually, these components are already working well individually. However, they may break when integrated with other components. Integration testing aims to pinpoint those communication issues.
Software is often built from many individual software components or modules. Issues between those modules can always happen for many reasons:
Integration testing protects you from those downfalls.
There are several strategies to perform integration testing, each of which has its own advantages and disadvantages, with the 2 most common approaches being:
Incremental Approach is further divided into 3 different methods:
Big Bang Integration testing is an integration testing approach in which all modules are integrated and tested at once, as a singular entity. It is essentially “testing in a Big Bang fashion”.
The Big Bang integration testing process is not carried out until all components have been successfully unit tested.
Advantages:
Disadvantages:
Best Practices when using Big Bang testing:
Incremental integration testing is an approach in which 2 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:
Disadvantages:
Incremental integration testing can be further divided into 3 smaller approaches, each also comes with its own advantages and disadvantages that QA teams need to carefully consider for their projects. These approaches are named based on the level of impact of the software components being integrated have on the overall system, including:
To better understand these 3 concepts, we must first define low-level components and high-level components.
The concept of “low” vs “high” here refers to the position of the software component in the system hierarchy when performing integration testing.
When referring to low-level component, we are talking about the very basic building blocks of the software, performing the most fundamental and basic tasks in the system. They are basic data structures or simple functions that perform a specific and low-impact task in the software.
On the other hand, when referring to high-level component, we are talking about the most comprehensive and complex components of the system, representing the complete system behavior. They tend to perform more abstract and far-reaching tasks such as data processing, data management, or tasks involving complex encryption and security mechanisms. If these high-level modules are buggy, the entire system is put at risk.
You can have a look at the table below to better understand the differences between the two types of components, and examples for them in the context of an eCommerce website:
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 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.
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.
With the top-down approach, testers start with the highest-level modules, then gradually move to lower-level modules, hence the term “top-down”.
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
These 2 approaches inherit all of the advantages and disadvantages of incremental integration testing. The major differences between them lie in the specific situations and scenarios in which they are used.
The final decision to choose which type also depends on the project's characteristics, development approach, and testing requirements.
We should use bottom-up integration testing when:
Similarly, we should use top-down integration testing when:
Note that when choosing the bottom-up testing approach, we may need to build a stub to substitute for high-level modules that are not yet developed, while for the top-down testing approach, we may need to build a driver to replace the unavailable low-level modules.
Stubs and drivers are essentially a simplified version of the actual software component so that the testing team can proceed without having to wait for the real dependent components.
Sandwich Testing (also known as Hybrid Integration Testing) is an approach in which testers employ both top-down and bottom-up testing simultaneously.
Advantages:
Disadvantages:
In simple terms, integration testing is about trying to see how 2 or more things work together. We can perform it to see how 2 service classes interact with each other, how a service interacts with a data store, and how the UI responds to the backend.
In the case of an eCommerce website, there are several integration test cases to consider:
Check out: Full Test Case Template For Better Test Management
In the case of a banking application, these are the common integration testing cases:
Want To Do Integration Testing Faster & Better? It Starts With Katalon
To have a holistic integration test strategy covering all aspects of the application, it is crucial for testers to align with the developers and clients on their vision, and optimize their strategy along the way. No matter what, it is still essential to follow integration testing best practices:
Integration testing can be conducted manually by QA teams, usually in parallel with the development process.
The process usually starts with the development team committing new code to the shared repository, then a series of unit tests are triggered to validate the new code. After that, QA testers start to select different components based on the test plan to manually inspect and interact with, seeing if any defects arise.
Read More: A Complete Guide To Manual Testing
However, performing integration testing manually is not always the best choice.
Automated integration testing, either with the help of automation testing frameworks like Selenium or automation testing tools, can significantly speed up the process and free up resources for other activities.
→ Check out the top automation testing tools on the market
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. |
Read More: Unit Testing vs Integration Testing: In-depth Comparison
Simply put, integration testing verifies interactions between individual components or modules, whereas end-to-end testing verifies the flow of a complete user journey or business process.
| 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
|
Read More: End-to-end testing vs Integration Testing
Integration testing is an essential part of software testing as it validates if the modules can communicate well with each other, which is something that can’t be tested with unit testing. We can take either the Big Bang approach or the Incremental approach to integration testing, both with their own advantages and disadvantages.
Performing integration testing typically involves API and UI Integration Testing. However, professionals may not be able to perform those tests in one place, and have to constantly switch from 1 tool to another when they need to perform different testing types.
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.
A major pain of testers performing UI Testing is the huge number of devices and browsers to test the application on. The UI of an application may look perfectly fine on this device but is messy on another due to differences in screen sizes, resolution, or other technical specifications. Katalon allows you to stay within budget thanks to its cross-platform, cross-browser testing capabilities on cloud environments.
Katalon Platform is also built for test maintenance. When an application is updated, testers need to review if their test cases need to be adapted for the code changes. This is a daunting task that Katalon Platform can help you with thanks to its page object design model approach.
Katalon stores locators across tests in an object repository. When changes occur, locators and artifacts are already grouped together to make updates easily.
Download & Start Integration Testing with Katalon Free Trial