We have studied about various Software developments lifecycle models. All the SDLC models have Integration testing as one of the layers. In my opinion, Integration testing is actually a “level” of testing rather than a “Type” of testing.
Many a time we feel that Integration testing involves writing code snippets to test the integrated modules, so it is basically a white box testing technique. This is not fully wrong, but I feel the concept of Integration testing can be applied in Black box technique too.
When talking in terms of testing large application using black box testing technique, involves the combination of many modules which are tightly coupled with each other. We can apply the Integration testing technique concepts for testing these types of scenarios.
In the subsequent section, I will try to elaborate the concept of Integration testing and its implementation in both White box and Black box technique.
What You Will Learn:
We normally do Integration testing after “Unit testing”.
Once all the individual units are created and tested, we start combining those “Unit Tested” modules and start doing the integrated testing. So the meaning of Integration testing is quite straightforward- Integrate/combine the unit tested module one by one and test the behaviour as a combined unit.
The main function or goal of Integration testing is to test the interfaces between the units/modules.
The individual modules are first tested in isolation. Once the modules are unit tested, they are integrated one by one, till all the modules are integrated, to check the combinational behaviour, and validate whether the requirements are implemented correctly or not.
Here we should understand that Integration testing does not happen at the end of the cycle, rather it is conducted simultaneously with the development. So in most of the times, all the modules are not actually available to test and here is what the challenge comes to test something which does not exist!
There are fundamentally 2 approaches for doing Integration testing:
Let’s consider the below figure to test the approaches:
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. Module 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 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.
This technique starts from the topmost module and gradually progress 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 a snippet which accepts the inputs/requests from the top module and returns the results/ response. This way, in spite of the lower modules, do not exist, 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, Stub module may turn out to be bigger than the stimulated module.
Both Stubs and drivers are dummy piece 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 behaviour
Let’s conclude some difference between Stubs and 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|
The only change is Constant in this world, so we have another approach called “Sandwich testing” which combines the features of both Top-down and bottom-up approach. When we test huge programs like Operating systems, we have to have some more techniques which are efficient and boosts more confidence. Sandwich testing plays a very important role here, where both, the Top down and bottom up testing are started simultaneously.
Integration starts with the middle layer and moves simultaneously towards up and down. In case of our figure, our testing will start from B1 and B2, where one arm will test the upper module A and another arm will test the lower modules B1C1, B1C2 & B2C1, B2C2.
Since both the approach starts simultaneously, this technique is a bit complex and requires more people along with specific skill sets and thus adds to the cost.
Now let’s talk about how we can imply integration testing in Black box technique.
We all understand that a web application is a multitier application. We have a front end which is visible to the user, we have a middle layer which has business logic, we have some more middle layer which does some validations, integrate some third party APIs etc., then we have the back layer which is the database.
Let’s check the below example:
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 displayed and I charge accordingly to my clients.
GenNext software developed this product for me and below was the architecture:
UI – User Interface module, which is visible to the end user, where all the inputs are given.
BL – Is the Business Logic module, which has all the all the calculations and business specific methods.
VAL – Is the Validation module, which has all the validations of the correctness of the input.
CNT – Is the content module which has all the static contents, specific to the inputs entered by the user. These contents are displayed in the reports.
EN – Is the Engine module, this module reads all the data that comes from BL, VAL and CNT module and extracts the SQL query and triggers it to the database.
Scheduler – Is a module which schedules all the reports based on the user selection (monthly, quarterly, semiannually & annually)
DB – 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:
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 scenario, the data entered in the UI module gets converted into XML file which is interpreted by the 3 modules BL, VAL and CNT. The EN module reads the resultant XML file generated by the 3 modules and extracts the SQL from it and queries into the database. The EN module also receives the result set and converts it into an XML file and returns it back to the UI module which converts the results in user readable form and displays it.
In the middle we have the scheduler module which receives the result set from the EN module, creates and schedules the reports.
So where Integration testing does comes into the picture?
Well, testing whether the information/data is flowing correctly or not will be your integration testing, which in this case would be validating the XML files. Are the XML files generated correctly? Do they have the correct data? Are the data is being transferred correctly from one module to another? All these things will be tested as part of Integration testing.
Try to generate or get the XML files and update the tags and check the behaviour. This is something very different from the usual testing which testers normally do, but this will add value to the testers knowledge and understanding of the application.
Few other sample test conditions can be as follows:
We feel that Integration testing is complex and requires some development and logical skill. That’s true! Then what is the purpose of integrating Integration testing in our testing strategy?
Here are some reasons:
This is all about Integration testing and its implementation in both White box and Black box technique. Hope we explained it clearly with relevant examples.
About the author: This article is written by STH team member Shilpa C. Roy. She is working in software testing field for the past 9 years in domains like Internet advertising, Investment Banking and Telecom. She has also cleared the CTAL test manager exam with good score.
Let us know your queries in comments below.