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.
- 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.
- 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.
- 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.
- 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.
- It is appropriate for small systems.
- The integration process is good
- 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:
- Bottom-up approach
- 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.
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: