Integration testing is carried out after unit testing and before integration testing when individual software units/module are combined and tested as a group. The purpose of an integration test is to expose the issues/bug that appears after the integration of separate modules. It can use any method white box, black box, and gray box testing method. It is performed by either developer themselves or by the individual tester.There are various approaches that are followed for integration test:-
Top Down Integration Test
In this approach, top level units are tested first and lower level of units are tested step by step after that. This approach is opted when top down development approach is followed. Test stubs are needed to simulate lower level units which are not developed during the initial phase of development, especially when interaction with the external environment is needed. Thus these stubs act as a temporary replacement for those modules that will be completed in future. For example, in below diagram, we know that upper modules 1,2,3 are available for integration test while below modules are still under development and thus are replaced by stubs for testing.
The Top-down approach provides a consistency because integration is performed in an environment which is almost equivalent to reality But the drawback with this is that stubs sometimes are more complex to write than they seem to be and basic functionality is tested at the end of the cycle.
Bottom Up Integration test
In this approach testing flows from bottom to top, thus smaller unit integration are tested first. This approach is an option when development is done from Bottom to up. Drivers programs are created to simulate the main module. Thus these driver programs act as a replacement for the main module if they are not developed.
In this approach development and testing can be done together so that product will be efficient as per customer requirement but in this driver, the module must be produced and the program as an entity does not exist until the last module is developed.
Stubs and Drivers
Stubs and Drivers are two types of test harness i.e, they are the collection of software and test data which is configured so that we can test a program unit by simulating the different set of conditions while monitoring the behavior and outputs. They both are dummy modules which are just created for test purpose.
Why do we have stubs?
Suppose we have a function
Function A:– Calculates the total marks obtained by a student in an academic year and its derive its value from another Function B.
Function B:– Calculates the marks obtained in a particular subject.
Now you have finished working on Function A and wants to test it. But the problem you will face is that you cannot test Function A until you have inputs from Function B. And Function B is still under development.
In this scenario, you have to create a dummy function to replace Function B to test your function. This dummy function gets called by another function. Such a dummy is called a Stub. Also, you can see that since Function A is dependent on function B and Function A is developed earlier, which means we are following top-down testing approach. So in a simple language stubs are “called” programs, which are called in to test the major module’s functionality.
To understand why we need a driver, suppose we are finished with Function B and is waiting for Function A to be developed. In this case, we will create a dummy to call the Function B. This dummy is called the driver. Drivers are thus the ones, which are the “calling” programs. Drivers are used in bottom-up testing approach. Drivers are dummy code, which is used when the sub-modules are ready but the main module is still not ready.