Logical extension of unit testing is called Integration Testing.
Objective here is to make sure that the interaction of two or more components produces results that satisfy functional requirement. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. In Integration Testing the test cases are developed with the purpose of exercising the interface between the components. Integration Testing can also be treated as testing assumption of fellow programmer. Integration testing identifies problems that occur when units are combined.
By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
Integration Testing can be performed in various ways but here are the following three strategies:
- Top-down approach: Here Integration Testing requires the highest-level modules be 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 early release of limited functionality.
- Bottom-up approach: Here Integration Testing requires the lowest-level units 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 early release of limited functionality.
- Third approach: Sometimes referred to as the umbrella approach, requires testing along functional data and control-flow paths. First, the inputs for functions are integrated in the bottom-up pattern discussed above. The outputs for each function are then integrated in the top-down manner. The primary advantage of this approach is the degree of support for early release of limited functionality. Integration Testing 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.
Here is the above picture first the lowest level modules “B” and “C” are tested with drives then next higher module “A” is testing with a drive integrated with module “B” and “C”. Finally the integration will be continued till the top-level module is tested. The total number of tests required by this technique is the sum of the cyclomatic complexities of all modules being integrated.