What is Integration Testing and How It is Performed?
We have studied about various Software developments lifecycle models. All the SDLC models have Integration testing as one of the layers. In my opinion, Integration testing is actually a “level” of testing rather than a “Type” of testing .
Many a time we feel that Integration testing involves writing code snippets to test the integrated modules, so it is basically a white box testing technique. This is not fully wrong, but I feel the concept of Integration testing can be applied in Black box technique too.
When talking in terms of testing large application using black box testing technique. involves the combination of many modules which are tightly coupled with each other. We can apply the Integration testing technique concepts for testing these types of scenarios.
In the subsequent section, I will try to elaborate the concept of Integration testing and its implementation in both White box and Black box technique.
Once all the individual units are created and tested, we start combining those “Unit Tested” modules and start doing the integrated testing. So the meaning of Integration testing is quite straight forward- Integrate/combine the unit tested module one by one and test the behavior as a combined unit.
The main function or goal of Integration testing is to test the interfaces between the units/modules.
The individual modules are first tested in isolation. Once the modules are unit tested, they are integrated one by one, till all the modules are integrated, to check the combinational behavior, and validate whether the requirements are implemented correctly or not.
Here we should understand that, Integration testing does not happens at the end of the cycle, rather it is conducted simultaneously with the development. So in most of the times all the modules are not actually available to test and here is what the challenge comes to test something which does not exists!
There are fundamentally 2 approaches for doing Integration testing:
- Bottom up approach
- Top down approach.
Let’s consider the below figure to test the approaches:
Bottom up approach :
Bottom up testing, as the name suggests starts from the lowest or the innermost unit of the application, and gradually moves up. The Integration testing starts from the lowest module and gradually progresses towards the upper modules of the application. This integration continues till all the modules are integrated and the entire application is tested as a single unit.
In this case, modules B1C1, B1C2 & B2C1, B2C2 are the lowest
module which is unit tested. Module B1 & B2 are not yet developed. The functionality of Module B1 and B2 is that, it calls the modules B1C1, B1C2 & B2C1, B2C2. Since B1 and B2 are not yet developed, we would need some program or a “stimulator” which will call the B1C1, B1C2 & B2C1, B2C2 modules. These stimulator programs are called DRIVERS .
In simple words, DRIVERS are the dummy programs which are used to call the functions of the lowest module in case when the calling function does not exists. Bottom up technique requires module driver to feed test case input to the interface of the module being tested.
Advantage for this approach is that, if a major fault exists at the lowest unit of the program, it is easier to detect it, and corrective measures can be taken.
Disadvantage is that the main program actually does not exist until the last module is integrated and tested. As a result, the higher level design flaws will be detected only at the end.
Top down approach
This technique starts from the top most module and gradually progress towards the lower modules. Only the top module is unit tested in isolation. After this, the lower modules are integrated one by one. The process is repeated until all the modules are integrated and tested.
In the context of our figure, testing starts from Module A, and lower modules B1 and B2 are integrated one by one. Now here the lower modules B1 and B2 are not actually available for integration. So in order to test the top most modules A, we develop “STUBS ”.
“Stubs” can be referred to as code a snippet which accepts the inputs / requests from the top module and returns the results/ response. This way, in spite of the lower modules do not exist, we are able to test the top module.
In practical scenarios, behavior of stubs is not that simple as it seems. In this era of complex modules and architecture, the called module, most of the time involves complex business logic like connecting to a data base. As a result creating Stubs becomes as complex and time taking as the real module. In some cases, Stub module may turn out to be bigger than stimulated module.
Both Stubs and drivers are dummy piece of code which is used for testing the “non- existing” modules. They trigger the functions / method and return the response, which is compared against the expected behavior
Let’s conclude some difference between Stubs and Driver: