Integration Testing: Overview on How to Perform, its Types, and Tools

It is not enough to know that each software unit works correctly on an individual basis. It is also essential to make sure that these units can interact with each other as required.

Different components are built by different developers who may understand project requirements and business logic in different ways. For this reason, it is important to check whether every developer has got it right and developed corresponding components in compliance with the specifications. Integration testing is incredibly useful in these terms as it helps reveal various misunderstandings.

Integration testing pays particular attention to the data stream. It is indeed important as data tend to undergo numerous changes while being moved from one component to another. These data modifications may cause serious defects later. Thanks to integration testing, serious issues can be identified and eliminated at the outset enabling teams to save a ton of time and money.

Integration testing plays an important role because it also checks the software component interaction with different external tools and APIs. In such a way, QA engineers can make sure that data sent by these APIs or tools is accurate, and that generated in return responses are appropriate as well.

Under current conditions, project requirements are frequently changed. As a result, developers quite often deploy the changes missing out on unit testing. Therefore, integration testing is an additional defense line that can catch possible defects as far in advance as possible.

Big Bang Integration Testing

If a team executes big bang testing, all components of the software are joined together at a single blow to be tested as a single entity. This attitude requires minimum planning and is appropriate mostly for simple projects, but when it comes to large-scale ones, big bang testing is hardly the best possible option. First of all, QA engineers can get to integration testing only when work on the development and integration of all components is finished up, and this, in its turn, can take plenty of time. Besides, as all developed components are combined with one stroke, there is no chance to test critical components precisely, and if during testing any issue is noticed, it can be rather challenging and time-intensive to identify which component has triggered a corresponding problem.

Incremental Integration Testing

During incremental integration testing, at first, just a few logically related components are integrated to be tested for appropriate functioning. Later other logically related components are gradually integrated and checked. Such incremental integration enables QA experts to identify defective components with ease.

Still, incremental integration testing, in its turn, can be executed in a few ways as well. Let's consider each one.

Bottom-up testing

When bottom-up testing is used, a team in the first instance integrates and tests the lower software components and little by little proceeds to the higher software components.

In this context, it is worth remarking that the lower software components undergo testing while the higher components are not ready yet. To emulate these unavailable components, QA engineers make active use of drivers that provide corresponding inputs for the lower components.

Bottom-up testing is useful as critical issues at the lower level can be uncovered at the outset, and all the necessary actions can be taken in due time. On the other hand, its major shortcoming is that possible critical defects in the higher components are revealed at the extreme end.

Top-down testing

As its name implies, this integration testing, first of all, focuses on the higher components. Later, the lower components are added and tested bit by bit.

As well as bottom-up integration testing, top-down integration testing is also conducted while not all software components are available. To solve the problem of lower component absence, the stubs are designed. A stub can be defined as a special piece of code that stands in for an unavailable lower component getting the requests and inputs from the higher components and sending the corresponding responses and results in return. Due to stubs, higher components can be verified even though the lower components haven't been developed yet.

The key merits of this integration testing type are:

However, this integration testing type is not perfect as well. Its chief shortcoming is the necessity to create plenty of stubs. When highly sophisticated software is developed, the stub creation can take even more time than emulated feature development.

Hybrid testing

Hybrid testing is a simultaneous execution of the two previous types of integration testing. i.e. bottom-up and top-down. Hybrid testing begins with the medium level and contemporaneously progresses up and down. So, you may guess that in this circumstance both drivers and stubs are actively leveraged.

In general, hybrid testing is rather complicated and requires more investments and resources as well as particular skills and experience.