What is Integration Testing? Definition, Tools, and Examples
Among the major software testing types – unit testing, functional testing, integration testing (all-pairs testing), system testing, and acceptance testing, integration testing holds an inevitable place in the testing phase of the software development life cycle. This is because it validates the integrity of the whole application before the rigorous system testing.
According to a study, poor quality assurance and quality control strategy cost software organizations a whopping $2.8 trillion US dollars. But, the actual cost is far greater than monetary loss. As per DotComInfoway, 62% of people tend to uninstall an app when they experience an app crash, freeze, or software error. In order to avoid such monetary loss, organizations stress more on their software testing process.
Kelsey Hightower, the Principle Engineer for Google Cloud, considers integration testing to be of high priority, especially for FinTech applications.
Why? Let’s find out!
What is Integration Testing?
Integration testing is software testing where modules get logically integrated and tested as one complete system test. It aims to expose any defects, bugs, or errors in the interaction between these software modules, while emphasizing on the data communication between various modules. Thus, it’s also known as “I & T” (Integration and Testing). Integration testing can be conducted using manual testing or automated testing tools.
Objectives of Integration Testing
To analyze working of integrated software modules
The primary objective of integration testing is to ensure the connectivity between individual modules by examining the logic implemented and rendering values as per the requirements of the test plan. There are no mock objects involved and therefore, it provides a real world perspective.
To ensure smooth integration between modules and third-party tools
Interaction between modules and third-party tools is tested to ensure that the data accepted by API is correct and if the desired response is being generated.
To fix exception handling defects
Integration testing pinpoints weak spots and red flags to minimize exception handling defects before releasing the final build. Naturally, undetected integration failures are expensive to fix after the release of the product. And so, the developers usually perform entire system-level analysis to remove the defects.
Advantages of Integration Testing
Independent testing process
You don’t need to wait for all the modules to be available and unit tested. As soon as the relevant modules are available, the testing process continues and QA can proceed with the integration testing.
High code coverage
It allows a thorough analysis of the entire system. With such a broad scope, the chance of missing out on a crucial connectivity issue is close to zero.
You can detect any defect or security issue during the initial phases of the software testing life cycle(STLC) using integration testing. This saves a lot of time and offers developers superior control over the product.
Functional Testing vs Integration Testing: A Detailed Guide on the Differences
Difference between Unit Testing and Integration Testing
|Unit Testing||Integration Testing|
|Each software module is separately tested||All modules are combinedly tested|
|Tester is aware of the software’s internal design||Tester is unaware of the software’s internal design|
|Unit testing can be performed anytime||Integration testing is performed after unit testing|
|It’s a black-box testing||It’s a white-box testing|
|Developers perform unit testing||Testers perform integration testing|
|Defects detection is easy||Defects detection is hard|
|Less costly||More costly|
Examples of Integration Testing
Let’s briefly understand how Integration testing works with the help of two real-life scenarios.
Assuming, you have a mail application with critical modules:
- login page
- Mailbox module
- Delete mail module
Here you don’t need to test the functionality of the individual pages. Instead, you can focus more on how they are interlinked with each other, for example, on interlinking between the login page and the mailbox page.
Similarly, the integration between the mailbox module and delete mails module needs to be verified. An ideal test case for such a scenario should be like this:
Suppose you want to check integration between a large number of modules of a banking application for amount transfer functionality.
Steps to follow:
- First, log in as “P” and transfer an amount of $200 to a user named “Q.”
- Second step is to check for the “amount transferred” confirmation message on the screen.
- Next, cross-check if the balance of “P” is reduced by $200 after the transaction.
- Now, log out as “P” and login as “Q.”
- Navigate to the balance page to check if the amount transferred is credited to the account.
Now you can do integration testing using different approaches. You can select one as per the project needs and resources allocation.
Types of Integration Testing
Integration testing is done by combining different functional units and testing them to examine the results. There are mainly 4 different types of integration testing as follows –
Big-Bang Integration testing
Use this approach when all the components or modules of the application are readily available.
Once the module development is finished, they are integrated and tested together in one go. Due to the sheer volume of this type of testing, it is generally suitable for testing compact applications.
Use case: This approach is used when the bundle has entire software in it.
- Convenient for small systems
- Requires minor planning
- It covers all the modules
- Not recommended for large-scale systems as fault localization is complicated.
- As the prerequisite of this approach is the completion of all modules, the testing team remains extremely time-bound when executing the test.
- Since all the modules are tested at once, you can’t test modules based on priority or critical functionality. Even the peripheral modules are tested equally as compared to high-risk modules.
In bottom-up integration testing, the tester starts from the bottom of the application’s control flow and gradually moves upward. Like two approaches i.e., big bang and top-down, there is a high possibility that modules at the upper stage are not yet completed by the development team when lower modules are being tested. In such cases, the tester needs to simulate the missing module’s functionality by using suitable drivers.
Use case: This incremental testing approach is used to identify any crucial flaw in the lower-level modules of the application.
- Since it is based on the control flow of the application, fault localization is much easier.
- Unlike the big bang approach, no time is wasted to get started with the bottom-up testing approach.
- In this approach, you can do development and testing simultaneously to meet customer specifications efficiently.
- Critical/top-level modules of the control flow of the application are tested last.
- There is no room for an early prototype.
- Except for the top-level, test drivers need to be created for modules at all levels.
- Defects between interfaces can be identified only by the end of the testing cycle.
Top-Down Integration Testing
This approach follows the natural control flow hierarchy, i.e., top to bottom. For example, you have a fitness app with four modules – A login page, a profile page, a workout page, and a payment page.
The testing of the application will start from the crucial top-level module. For example, first, the login page will be tested and integrated, and then gradually, other low-level modules will be tested. Finally, stubs are used in case the missing modules are not ready.
L: Login page
P: Payment page(yet to be created)
O: Track Progress page
R: Workout page (yet to be created)
Use case: This approach is crucial when the defect is likely to occur in the top-level modules of the application.
- Easier fault localization.
- It gives you early access to prototyping.
- Reveal design flaws at early stage.
- Modules at a lower level are tested inadequately.
Also known as “hybrid testing,” it has top-down and bottom-up testing scenarios combined together. In this test strategy, the top modules are put together for testing in conjunction with the lower-level modules and vice versa. This strategy uses both stubs and drivers.
Use case: This incremental integration testing approach is beneficial for extensive projects with several subprojects in them.
- Both top-down and bottom-up approaches can be performed in parallel to each other
- Large-scale applications can benefit tremendously from this approach.
- It is an expensive approach.
- Not suitable for small-sized applications
- Different testers with unique skillsets are required to carry out this testing approach.
How Much Does Software Testing Cost? 9 Proven Ways to Optimize it
Integration Testing Tools
The below-mentioned tools are standard platforms that QA teams prefer for specific operations.
It is a popular tool used for both unit and integration testing. This integrated software testing solution significantly reduces time and cost by automating unit and system integration testing. It also features Software Quality Metrics for improving and monitoring the testing key metrics. In addition, it creates missing modules with the help of stubs and drivers to simulate the code’s functionality.
- Integrates with multiple tools such as IBM Rational and Green Hills
- Features automatic code generation of Stubs and Drivers
- Offers test case reusability for regression testing
- Highlights high-risk code using inbuilt code complexity analysis
It is an open-source integration testing framework supporting a wide range of message protocols and data formats. This tool works best for complex integration testing and provides superior validation capabilities for multiple formats like XML, JSON, and plain text. It requests and responds on both the server and client-side. In addition, it supports multiple protocols such as HTTP, JMS, and SOAP.
- It is a low-cost solution to all your integration testing needs
- Allows validation of database
- Features re-creation of error
- Provides test plan and documents for the test coverage
LDRA is a cost-effective tool that offers various sets of integration testing tools to match the compliance standards of different organizations. Its test suite offers – static and dynamic analysis, code workflow, code coverage analysis, design reviews, and more.
- Seamless execution of unit and integration testing
- Automates software certification and approval evidence
- Offers common test environment support for integration testing in a wide range of projects
- Coverage analysis of code
It is an integration and unit testing tool designed especially for embedded software. This tool comes with CTE (classification of tree editor) to write tests and TDE (test data editor) for editing test data. It also takes care of the entire test organization, management, requirements, and traceability. In addition, TESSY supports test engineers in analyzing the internal values of the component variables.
For example – if you want to create a battery evaluation model for an EV. The voltage data needs to be collected from a separate module to evaluate the remaining power. It helps engineers with the validation of data accuracy while transferring data between modules.
- Creates test report for every test execution
- Features comprehensive test report
- You can use a single license by multiple users
- It supports popular languages like C and C++
Protractor is another open-source framework, an automation testing tool for web-based application testing. It is designed specifically for testing Angular and AngularJS applications. However, its use case is not limited to Angular applications. The framework offers integration with Jenkins/Browserstack/Grunt for automating the test server. It runs the tests in a real browser and mimics the interaction as a user. Protractor has extensive browser support, including Firefox, Chrome, Safari, and Internet Explorer.
- Allows execution of multiple instances of your application
- Used for integration testing, end-to-end testing, and testing of dynamic web applications.
- Performs testing from the end-user perspective
Best Practices for Integration Testing
We’ve learned a set of best practices for integrating testing from our diverse software engineering experience. Here’s it:
Start integration testing as early as possible
The traditional waterfall development method conducts unit testing before integration testing since bug fixes at later stages can result in costly affairs.
But the modern agile methodology allows simultaneous development of modules, so you can perform integration testing at earlier stages, detect issues and make changes in the business logic as you move forward in the development. This comprehends the product development progress as you can detect and fix bugs earlier without waiting for one module to be finished. Moreover, if there are missing or under-development modules, you can replace them with stubs and drivers.
Keep business logic separate from integration testing.
Most of the time, people tend to confuse unit testing with integration testing. However, if you don’t separate them, it could have dire consequences on the run-time of a particular test case. Unit testing focuses on detecting bugs in business logic. However, integration testing takes a while to execute; therefore, involving it in every business logic will affect your productivity.
Thus, perform it only on the daily build, i.e., once a day, and focus on whether the various modules are working in sync with each other.
Integration testing has an extensive scope as it is spanned over several modules in your application. Unlike unit testing, there is no easy way of analyzing the origin of the fault in integration testing.
As such, logging your test results is the only way to discover the problem. You can use a competent logging framework that provides detailed information about the completion of performance tests and record the performance of the software.
Integration testing is an essential part of your SDLC. Proper execution of it saves you from post-release updates and bug fixes. We, at Simform, have experienced multiple projects where integration testing came off as an easier gateway to finding defects between module’s interactions.
Let us know in the comment section what other best practices you follow for executing integration testing. We would love to hear your views.
Good. I think all intending developers should be made to read this post