Integration Testing

Introduction to Integration Testing:

When the modules are under the process of development, the developers develop some interfaces and integrate the module with the help of those interfaces. Here integration is the process of assembling unit-tested modules. We need to test the following aspects, which have not been addressed previously while independently testing the modules:

• Interfaces: To ensure "interface integrity," the transfer of data between modules is tested. When data is passed to another module, by way of a call, there should not be any loss or corruption of data. The loss or corruption of data can happen due to mis-match or differences in the number or order of calling and receiving parameters.
• Module combinations may produce a different behavior due to combinations of data that are not exercised during unit testing.

Global data structures, if used, may reveal errors due to unintended usage in some module.

Integration Testing falls under the category of white box testing.

Following four approaches are generally adopted by the developers while integrating the modules.

To illustrate the methodology, let us consider the following arrangement of modules say M1, M2, M3 ……. M7

1) Top Down Approach (TDA):

Involves development of all the topmost / parent modules before hand followed by due integration with child modules.

This approach uses a Program called "Stub". While integrating the modules with this Top Down Approach, if at any stage it is found that some mandatory module is missing, then in such an event that particular module is replaced with a temporary program known as "Stub".

The testing starts with M1. To test M1 in isolation, communications to modules M2, M3 and M4 needs to be simulated by the tester by some means, since these modules may not be ready yet. To simulate responses of M2, M3 and M4 whenever they are to be invoked from M1, "stubs" are created. Simple applications may require stubs, which would simply return the control to their superior modules. More complex situation demand stubs to simulate a full range of responses, including parameter passing. Stubs may be individually created by the tester or they may be provided by a software testing harness, which is a sort of software specifically designed to provide a testing environment.

In the above illustration, M1 would require stubs to simulate the activities of M2, M3 and M4. The integration of M3 would require a stub or stubs for M5 and M4 would require stubs for M6 and M7. Elementary modules i.e. the modules which do not call subordinates would not require any stubs.

Advantages of Top down Approach:
a) This approach is advantageous if all major flaws are captured towards the top of the program

b) Early skeletal program allows demonstrations and boosts the moraleDisadvantages of Top down Approach:
a) Stub modules are essential

b) Test conditions my be impossible, or very difficult, to create

c) Observation of test output is more difficult, as only simulated values will be used initially. For the same reason, program correctness can be misleading

2) Bottom Up Approach (BUA):
Involves development of all the elementary modules or child modules before hand followed by due integration with the corresponding parent modules.

This approach uses a Program called "Driver". While integrating the modules with this Bottom Up Approach, if at any stage it is found that some mandatory module is missing, then in such an event that particular module is replaced with a temporary program known as "Driver".

If M5 is ready, we need to simulate the activities of its superior, M3. Such a "driver" for M5 would simulate the invocation activities of M3. As with the stub, the complexity of a driver would depend upon the application under test. The driver would be responsible for invoking the module under test, it could be responsible for passing test data and it might be responsible for receiving output data. Here as well, the driving function can be provided through a testing harness or may be created by the tester as a program.

For the above-mentioned Bottom-Up example, drivers must be provided for modules M2, M5, M6, M7, M3 and M4. However there is no need for a driver for the topmost Module, M1.

Advantages of Bottom Up Approach:
a) This approach is advantageous if all major flaws are captured towards the bottom of the program
b) Test conditions are easier to create

c) Observations of test results are easier since "live" data is used from the beginning.

Disadvantages of Bottom Up Approach:
a) Driver modules are essential
b) The program as an entity does not exist until the last module is added

3) Big Bang Approach:
Once all the modules are ready after testing individually; the approach of integrating them finally at once is known as big bang approach.

Though Big Bang approach seems to be advantageous when we construct independent module concurrently, this approach is quite challenging and risky as we integrate all modules in a single step and test the resulting system. Locating interface errors, if any, becomes difficult here.

4) Hybrid Approach:
To overcome the limitations and to exploit the advantages of Top-down and Bottom-up approaches, a hybrid approach in testing is used. As the name suggests, it is a mixture of the two approaches like Top Down approach as well as Bottom Up approach.

In this approach the system is viewed as three layers consisting of the main target layer in the middle, another layer above the target layer, and the last layer below the target layer.

The Top-Down approach is used in the topmost layer and Bottom-Up approach is used in the lowermost layer. The lowermost layer contains many general-purpose utility programs, which are helpful in verifying the correctness during the beginning of testing.

Testing converges for the middle level target layers are selected on the basis of system characteristics and the structure of the code. The middle level target layer contains components using the utilities.

Final decision on selecting an integration approach depends on system characteristics as well as on customer expectations. Sometimes the customer wants to see a working version of the application as soon as possible thereby forcing an integration approach aimed at producing a basic working system in the earlier stages of the testing process
.