Hybrid Approach

Hybrid Approach is also called as Test Integration Approaches.

There are fundamentally 2 approaches for doing test integration:

1. Bottom-up approach
2. 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. Modules 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 a case when the calling function does not exist. The bottom-up technique requires the module driver to feed test case input to the interface of the module being tested.

The advantage of 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.

The 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 topmost module and gradually progresses 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 topmost modules A, we develop “STUBS”.

“Stubs” can be referred to as code snippets which accept the inputs/requests from the top module and return the results/ response. This way, in spite of the lower modules not existing, we are able to test the top module.

In practical scenarios, the 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 database. As a result, creating Stubs becomes as complex and time taking as the real module. In some cases, the Stub module may turn out to be bigger than the stimulated module.

Both Stubs and drivers are dummy pieces of code which are used for testing the “non-existing” modules. They trigger the functions/method and return the response, which is compared to the expected behavior.

Let’s conclude some difference between Stubs and Driver:

The only change is Constant in this world, so we have another approach called “Hybrid Approach” which combines the features of both Top-down and bottom-up approach.

In Hybrid Integration Testing, we exploit the advantages of Top-down and Bottom-up approaches. As the name suggests, we make use of both the Integration techniques.

Features of Hybrid Integration Testing

• It is viewed as three layers; viz – The Main Target Layer, a layer above the target layer and a layer below the target layer.
• Testing is mainly focused for the middle level target layer and is selected on the basis of system characteristics and the structure of the code.
•  Hybrid Integration testing can be adopted if the customer wants to work on a working version of the application as soon as possible aimed at producing a basic working system in the earlier stages of the development cycle.

Integration Testing Example

For example, you have to test the keyboard of a computer rather than unit testing but when you have to combine the keyboard and mouse of a computer together to see if it’s working or not then it is integration testing. So it is a prerequisite that for performing integration testing a system must be unit tested before.