What is Integration Testing?

Integration Testing is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before system testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing. 

Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test modules with those of other groups. Eventually, all the modules making up a process are tested together.

Integration Testing Strategies

The larger the project, the more importance we need to place on the integration strategy. Very small systems are often assembled and tested in one phase. For most real systems this is impractical for two major reasons: First, the system would fail in so many places at once that the debugging and retesting effort would be impractical. Second, satisfying any white box testing criterion would be very difficult because of the vast amount of detail separating the input data from the individual code modules. Most integration testing has been traditionally limited to “black box” techniques. Large systems may require many integration phases, beginning with assembling modules into low-level subsystems, then assembling subsystems into larger subsystems, and finally assembling the highest level subsystems into the complete system.

Top-Down Integration Testing

The top-down approach to integration testing requires the highest-level modules to be a test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for the early release of limited functionality.

Bottom-Up Integration Testing

The bottom-up approach requires the lowest-level units to be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management, and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for the early release of limited functionality.

Umbrella Approach

The umbrella approach requires testing along with functional data and control-flow paths. First, the inputs for functions are integrated into the bottom-up pattern discussed above. The outputs for each function are then integrated in a top-down manner. The primary advantage of this approach is the degree of support for the early release of limited functionality. It also helps minimize the need for stubs and drivers. The potential weaknesses of this approach are significant, however, in that it can be less systematic than the other two approaches, leading to the need for more regression testing.

Black Box Testing

Black box testing takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the test object's internal structure. This method of test design is applicable to all levels of software testing: unit, integration, functional testing, system, and acceptance. The higher the level, and hence the bigger and more complex the box, the more developers are forced to use black-box testing to simplify. While this method can uncover unimplemented parts of the specification, one cannot be sure that all existent paths are tested.

Integration Testing typically involves the following steps:

 Step 1: Create a Test Plan

Step 2: Create Test Cases and Test Data

Step 3: If applicable create scripts to run test cases

Step 4: Once the components have been integrated execute the test cases

Step 5: Fix the bugs if any and re-test the code

Step 6: Repeat the test cycle until the components have been successfully integrated