The term “integration testing” simply refers to the process of integrating or merging the unit-tested modules one at a time and evaluating how they behave as a cohesive whole.
The main goal of this testing is to evaluate the interfaces between the units/modules.
Integration testing usually comes after “unit testing”.We combine the “Unit Tested” modules and start the integrated testing procedure after each individual unit has been created and tested.
Testing the interfaces between the units/modules is the primary purpose of this testing.
Initially, each module is tested separately. Following unit testing, the modules are combined one after the other until all of them are merged. This is done to verify that the requirements have been correctly implemented and to examine combinational behavior.
It is important to realize that integration testing is carried out concurrently with development rather than at the conclusion of the cycle. Therefore, the challenge is to test something that doesn’t exist, even though most of the time all the modules are available for testing!
Why Integration Test
Integration testing can be challenging and demands development and logical expertise. What is the reason for incorporating this testing into our overall testing approach?
Here are some reasons:
- When apps are created in the real world, they are divided into multiple smaller modules, with each developer given a single module. One developer may use different logic than another, thus it’s critical to verify that the logic a developer uses meets expectations and produces the right value in accordance with specifications.
- Many a time, the face or the structure of data changes when it travels from one module to another. Some values are appended or removed, which causes issues in the later modules.
- Modules also interact with a few third-party tools or APIs, which also need to be tested to ensure that the data accepted by that API / tool is correct and that the response generated is also as expected.
- Frequent requirement change is a very common problem in testing. Many a time, the developer deploys the changes in unit testing. Integration testing becomes important at that time.
Advantages
This testing has several advantages, and a few of them are listed below.
- This testing ensures that the integrated modules/components work properly.
- Integration testing can start once the modules to be tested are available. This does not require another module to be completed for testing to be done, as Stubs and Drivers can be used for the same.
- It detects errors related to the interface.
Challenges
We have identified several challenges associated with the Integration Test.
#1) Integration testing means testing two or more integrated systems to ensure that the system works properly. Besides testing the integration links, it is necessary to perform exhaustive testing, considering the environment to ensure that the integrated system works properly.
There might be different paths and permutations which can test the integrated system.
#2) Managing Integration testing becomes complex because of a few factors involved in it like the database, platform, environment, etc.
When integrating a new system with the legacy system, extensive changes and testing are necessary. This concept is relevant when merging two legacy systems.
#4) Integrating two different systems developed by two different companies is a big challenge because the impact of changes made in one system on the other is uncertain.
To minimize the impact while developing a system, developers should consider a few things, such as possible integration with other systems, etc.
Types of Integration Testing
Given below is a type of Test Integration along with its advantages and disadvantages.
Big Bang Approach
Instead of integrating the modules one at a time, the Big Bang technique combines all of the modules at once. Once integrated, it checks to see if the system functions as intended. It becomes challenging to identify which module is causing the problem if one is found in the fully integrated module.
Finding a module with a problem itself takes a lot of time using the Big Bang approach, and once the defect is found, correcting it will cost more because it was discovered later..
Advantages of the Big Bang approach:
- It is a good approach for small systems.
Disadvantages of the Big Bang Approach:
- It is difficult to detect which module is causing an issue.
- The Big Bang approach requires all the modules together for testing, which leads to less time for testing as design, development, and integration would take most of the time.
- Testing takes place at once only, which thereby leaves no time for critical module testing in isolation.
Integration Testing Steps:
- Prepare Integration Test Plan.
- Prepare integration test scenarios & test cases.
- Prepare test automation scripts.
- Execute test cases.
- Report the defects.
- Track and re-test the defects.
- Re-testing & testing goes on until integration testing is complete.
Test Integration Approaches
There are fundamentally 2 approaches for doing test integration:
- Bottom-up approach
- Top-down approach.
Please consider the figures given below 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. Integration testing starts with the lowest module and gradually progresses towards the upper modules of the application.
We continue this integration until we integrate all the modules and test the entire application as a single unit.
In this case, modules B1C1, B1C2 & B2C1, B2C2 are the lowest modules which are unit tested. Modules B1 & B2 are not yet been 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 that 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 a module driver to feed a test case input to the interface of the module being tested.
The advantage of this approach is 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 does not exist until the last module is integrated and tested. As a result, we can only detect the higher-level design flaws 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, we integrate the lower modules one by one. The process is repeated until all the modules are integrated and tested.
In the context of our figures, testing begins with Module A, and we integrate the lower modules B1 and B2 one by one. Here are the lower modules B1 and B2 that are not available for integration. So, testing the topmost module A, we develop “Stubs”.
“Stubs” can be referred to as code a snippet that accepts the inputs/requests from the top module and returns the results/ response. This way, although the lower modules do not exist, we can test the top module.
In practical scenarios, the behavior of stubs is not as 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-consuming as the real module. Sometimes, the Stub module may be bigger than the stimulated module.
Both Stubs and drivers are dummy pieces of code which is 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 with some differences between Stubs and Driver:
| Stubs | Driver |
|---|---|
| Used in Top down approach | Used in Bottom up approach |
| Top most module is tested first | Lowest modules are tested first |
| Stimulates the lower level of components | Stimulates the higher level of components |
| Dummy program of lower level components | Dummy program for Higher level component |
We have an additional method called “Sandwich testing” that combines the advantages of top-down and bottom-up approaches because change is the only thing that is constant in our world. We need additional effective and confidence-boosting strategies when testing large programs, such as operating systems.
Here, sandwich testing is crucial, with top-down and bottom-up testing beginning at the same time.
Beginning with the middle layer, integration proceeds both up and down at the same time. Our testing will begin with B1 and B2 using our figure, with one arm checking the upper module A and the other arm evaluating the lower modules B1C1, B1C2, & B2C1, B2C2.
Since both approach starts simultaneously, this technique is complex and requires more people along with specific skill sets, thus adding to the cost.
GUI Application Integration Test
Now let’s talk about how we can imply integration testing in the Blackbox technique.
We all understand that a web application is a multi-tier application. We have a front end that is visible to the user. We have a middle layer that has business logic; we have another middle layer that does some validations, integrates some third-party APIs, etc., then we have the back layer which is the database.
Integration Testing Example
Check out the example below:
I am the owner of an advertising company, and I post ads on different websites. At the end of the month, I want to see how many people saw my ads and how many people clicked on my ads. I need a report for my ads to be displayed and I charge accordingly to my clients.
GenNext software developed this product for me and below is the architecture:
All of the inputs are entered into the UI module, which is visible to the end user.
All of the computations and business-specific techniques are contained in the Business Logic module, or BL.
The Validation module, or VAL, contains all of the input’s correctness validations.
The content module known as CNT contains all of the static contents that are unique to the user-inputted data. The reports appear with these contents.
The Engine module (EN) extracts the SQL query and sends it to the database after reading all of the data from the BL, VAL, and CNT modules.
A module called Scheduler arranges all of the reports according to the user’s preferences (monthly, quarterly, semiannually, and annually). The database is the database.
Now, having seen the architecture of the entire web application, as a single unit, Integration testing, in this case, will focus on the flow of data between the modules.
The questions here are:
- How will the BL, VAL, and CNT module read and interpret all the data entered into the UI module?
- Is BL, VAL, and CNT modules receiving the correct data from UI?
- In which format the data from BL, VAL, and CNT is transferred to the EQ module?
- How will the EQ read the data and extract the query?
- Is the query extracted correctly?
- Is the Scheduler getting the correct data for reports?
- Is the result set received by the EN, from the database is correct and as expected?
- Is EN able to send the response back to the BL, VAL, and CNT modules?
- Is the UI module able to read the data and display it appropriately to the interface?
In the real world, the communication of data is done in an XML format. So whatever data the user enters in the UI, it gets converted into an XML format.
In our case, the BL, VAL, and CNT modules interpret the XML file that is created from the data entered in the UI module. After reading the XML file that the three modules produced, the EN module takes the SQL out of it and runs queries against the database.
Additionally, the result set is received by the EN module, which transforms it into an XML file before sending it back to the UI module, which presents the results in a legible format.
The scheduler module sits in the center and generates and schedules the reports after receiving the result set from the EN module.
So where does integration testing come into the picture?
The information/data flow will be ascertained via your integration testing, which in this case would involve analyzing the XML files. Are the XML files generated correct? Do they have the correct data? Are there proper data flows between modules? These things will be tested as part of integration testing.
Try generating or acquiring the XML files, making changes to the tags, and watching how things behave. This will enhance their application knowledge and understanding, even if it is a big change from the testing that testers usually do.
A few other sample test conditions can be:
- Are the menu options generating the correct window?
- Are the windows able to invoke the window under test?
- For every window, identify the function that calls for the window that the application should allow.
- Identify all calls from the window to other features that the application should allow.
- Identify reversible calls: closing a called window should return to the calling window.
- Identify irreversible calls: calling windows closes before the called window appears.
- Test the different ways of executing calls to another window e.g. – menus, buttons, keywords.
Steps to Kick Off Integration Tests
- Understand the architecture of your application.
- Identify the modules.
- Understand what each module does.
- Understand how the data is transferred from one module to another.
- Understand how the data is entered and received into the system (entry point and exit point of the application).
- Segregate the application to suit your testing needs.
- Identify and create the test conditions.
- Take one condition at a time and write down the test cases.
Entry/Exit Criteria for Integration Testing
Entry Criteria:
- Integration test plan document is signed off and approved.
- Integration test cases have been prepared.
- Test data has been created.
- Unit testing of developed modules/Components is complete.
- All the critical and high-priority defects are closed.
- The test environment is set up for integration.
Exit Criteria:
- All integration test cases have been executed.
- No critical and Priority P1 & P2 defects are opened.
- Test Report has been prepared.
Integration Test Cases
Since the modules or components are previously unit tested—that is, the functionality and other testing features have already been covered—integration test cases primarily concentrate on the interface between the modules, integrated linkages, and data transmission between the modules.
So, the main idea is to test if integrating two working modules works as expected when integrated.
For example, Integration Test cases for LinkedIn applications will include:
- Verifying the interface link between the login page and the home page, i.e. when a user enters the credentials and logs, it should be directed to the homepage.
- Verifying the interface link between the home page and the profile page, i.e. profile page, should open up.
- Verify the interface link between the network page and your connection pages, i.e. clicking the accept button on Invitations of the network page should show the accepted invitation on your connection page once clicked.
- Verify the interface link between the Notification pages and the Say Congrats button, i.e. clicking the Say Congrats button should direct toward the new message window.
Many integration test cases can be written for this specific site. The above four points are just an example to understand what integration test cases are included in testing.
Is Integration a White box or Black box Technique
Integration testing techniques can be counted in both black boxes as well as white box techniques. Blackbox technique is where a tester need not have any internal knowledge of the system, i.e. coding knowledge is not required whereas white box technique requires internal knowledge of the application.
When conducting integration testing, it may involve testing the two integrated web services that will retrieve data from the database and deliver it as needed. In this case, the white box testing technique may be used, while the black box technique may be used to test the integration of a new feature into the website.
So it’s not specific if integration testing is a black box or white box technique.
Integration Testing Tools
There are several tools available for this testing.
Below is a list of tools:
- Rational Integration Tester
- Protractor
- Steam
- TESSY
For more details on the above tools, check this tutorial:
Top 10 Integration Testing Tools to Write Integration Tests
System Integration Testing
System Integration Test is done to test the complete integrated system.
The team tests modules or components individually in unit testing before integrating them. Once all the modules undergo testing, the team integrates them and performs system integration testing to test the system as a whole.
Difference Between Integration Testing and System Testing
One or two unit-tested modules are combined to test as part of integration testing, which verifies whether or not the combined modules function as intended.
System testing involves testing the system as a whole, that is, integrating all of the modules or components to ensure that everything functions as it should and that there are no problems as a result of the integrated modules.
Conclusion
Integration testing and its use in both white box and black box methodologies were the main topics of discussion. I hope we were able to clearly explain it using pertinent instances.
In the testing cycle, test integration is important since it aids in identifying flaws in the merging of modules. Early defect detection saves money and time. This ensures the integrated modules are operating properly.
You may be interested in:
Learn All Basic Concepts of SAP ABAP Quickly and Easily
SAP Business Workflow: Streamlining Business Processe
Ad Hoc agent assignment in Workflow
Configuring Events for HR Workflow
