Integration testing overview | David Tzemach
Updated: Jan 23, 2022
Integration testing is a testing approach used to test that two or more components work together correctly. Occasionally, integration tests test other aspects that are not directly related to the system components.
Examples:
Integration tests between systems and OS.
Integration tests between system modules (testing the interface and communication among modules).
System integration testing (interfaces with external organizations, integration of system packages, etc.).
When to start integration testing?
Integration testing is performed after component tests and before system tests.
[Unit Testing] -> [Component Testing] -> [Integration Testing] -> [System testing]
Why do we need integration tests?
There are many reasons for this type of test. Let’s examine two important reasons:
Integration tests can find bugs that appear only in specific situations, such as conflicts or dependencies between two modules.
Although each component is tested and approved before the integration phase, there is always a chance that the interface allowing the communication between the modules contains bugs.
Example:
Module A should be integrated with module B; both modules are tested and ready to interact. Let’s assume that the interface that should pass that output from module A into module B has a bug that does not encrypt/decrypt the data.
As a result, the two modules fail to interact and sometimes, module B receives corrupted and unexpected data that leads to a massive failure.
One thing to remember is that usually, each team or developer is assigned to develop a specific component and, in some cases, does not know the technical details or logic of the other module.
Integration testing allows us to test this uncertainty and validate that the gap is appropriately tested and that the modules work together.
Integration test techniques
There are two different approaches for conducting integration tests:
The big bang technique
Before performing the tests, the development team integrates all components and then tests them as one large system. Once done, the integration tests start for specific components.
The incremental test technique
In this technique, testing is done when logically related modules are integrated one by one and continue until the last module is integrated and tested. We need to use stubs and drivers to help run the tests without implementing the entire module to use this test technique.
When using the incremental approach, we can use two different methods, top-down and bottom-up.
Top-down integration testing - Using the top-down technique, we start testing from the top module to the last module (each module is integrated separately) based on the control flow hierarchy and the software architecture structure.
Due to the nature of this technique, we always have a top module that can interact with a lower module. The problem begins when the lower module is still not developed or just not ready for integration. In that case, we cannot run the tests, which affects the project timeline.
We can use stubs to overcome this problem and reduce the time wasted while waiting for the lower module. A stub is a term for a code snippet that can accept the request from the top module and return a result like the real module.
Bottom-up integration testing - From the name of this technique, we start the tests from the lowest module of the application and gradually progress towards the top until all modules are integrated and validated as a whole system.
The problem with this technique is similar to the problem we had in the top-down technique when we started to test the integration between two modules, one of which is still not ready to be integrated and tested.
To overcome this problem in the top-down technique, we used stubs. The equivalent here is another simulator called a “driver” that allows us to call the functions from the lowest module and simulate the test inputs to the tested module.
