What is Integration Testing?

It refers to the kind of testing in which software modules are combined logically and then tested as a collection. As we know that standard software projects have various software modules that are coded by many programmers. The objective of this testing is to disclose defects in an interaction between the software modules when they are combined.

Integration Testing concentrates on monitoring data interaction among these modules. Therefore, it is also known as 'I & T' (Integration and Testing) String Testing or Thread Testing.

Importance of Integration testing

As we know that integration testing is a complex process because it requires appropriate development and skills. So let’s discuss the importance of integration testing so that you can understand that it is essential for software testing.

1. In reality, when applications are created, it is separated into little modules, and individual developers are allocated 1 module. The logic executed by one developer is unique to another developer, so it gets essential to check whether the logic actualized by a developer is according to the desires and renders the right incentive as per the endorsed standards.
2. Modules likewise work with some other tools or APIs, which additionally should be tried that the information approved by that API/tool is accurate and that the response is created as expected.
3. A typical issue in testing is that frequent prerequisite changes sometimes the developer conveys the progressions without unit testing it. Hence integration testing gets significant around then.
4. Sometimes the face or the structure of information changes when it ventures out, starting with one module and then onto the next. A few qualities are affixed or expelled, which causes issues in the later modules.

Types of Integration testing

1. Big Bang Approach

It combines all of the modules at one time, which means it doesn't integrate the modules one by one. Big Bang Approach verifies that a system is working according to the expectation. If it detects any issue in the wholly integrated module, then it can be difficult to find out which module has made the issue. It is a time-consuming method of obtaining a module that consists of defects itself that can take time. After the detection of defects, it takes a high cost to eliminate the issues from it.

Pros:

• It is appropriate for small systems.
• The integration process is good

Cons:

• It is hard to detect a module that has the issue
• It is time and cost-consuming.

2. Test Integration Approaches

There are two types of integration approaches available in integration testing, and they are:

1. Bottom-up approach
2. Top-down approach.

So let's discuss these factors in brief.

2.1 Bottom-up approach

This approach suggests that you have to start the process from the lowest unit of an application and move upwards. This integration process proceeds until all of the modules are combined/ integrated and the complete application has been tested as a particular unit.

As we can see in the image that modules Q1R1, Q1R2, Q2R1, and Q2R2 are the least module that unit tested. Module Q1 & Q2 are not additionally developed. The functionality of Module Q1 and Q2 is that it describes the modules Q1R1, Q1R2 & Q2R1, and Q2R2. As Q1 and BR are not developed, we need some stimulators which will call the Q1R1, Q1R2 & Q2R1, and Q2R2 modules. These stimulator programs are known as DRIVERS.

In other words, DRIVERS are also called dummy programs which can be used for calling the functions of the lowest module in the case when a calling function doesn't exist. So, the bottom-up technique needs a module driver for feeding test case input to an interface of the module, which requires to be tested.

The benefit of this approach is that it is simpler to detect a significant issue at the lowest unit of any program so that that team can take corrective measures for it. The problem is that the program doesn't exist until the last module is tested. Hence, the higher-level design defects will be identified only in the end.

2.2 Top-down approach

This particular technique begins from the first module and steadily progresses to the lower modules. In this approach, only a top module is unit tested in isolation, and then lower modules integrate one by one. As we can see in the image that testing begins from Module A to the lower modules, and Q1 and Q2 are integrated one by one. At actual conditions, Q1 and Q2 are not available for integration.

For testing the first module P, we can develop "STUBS". "Stubs" are known as a code that accepts the inputs from the top module and then returns the response. So in this way, if the lower module does not exist, then we can test the head module. In this time of sophisticated modules as well as design, the called module, most of the time, includes complicated business logic such as connecting to a database.

As a result, building Stubs becomes as complicated as well as time taking as the actual module. Both Stubs and drivers are model code that is used in testing the "non-existing" modules. They can trigger the method and replace the response, which is related to the expected behavior.

Conclusion

As we know the objective of this testing is to disclose defects in an interaction between the software modules when they are combined. Integration Testing concentrates on monitoring data interaction among these modules. In this article, we have discussed Integration Testing completely regarding the overview features and their types so that you can understand this testing completely.

People are also reading:

• What is Automation Testing?
• Selenium IDE Tutorial
• What is Black Box Testing?
• Types of Software Testing
• What is White Box Testing?
• Integration Testing Tools
• What is Smoke Testing?
• What is Software Testing?
• What is Software Testing Life Cycle?
• What is SDLC?
• Top Selenium Interview Questions & Answers