Top Down Integration Testing Tutorial: Comprehensive Guide With Best Practices

The top down integration testing method is an incremental approach that involves joining two or more logically related modules. The process involves using dummy programs called Stubs and Drivers to stimulate the behavior of unintegrated lower-level modules.

This technique follows the control flow or architectural structure to test it from top to bottom. Unit testing is performed on the top module alone, followed by integration of the lower modules. In this way, all the modules are integrated and tested simultaneously.

Stubs are temporary replacements for modules and produce the same output as the actual products. In addition to the main module serving as a test driver, stubs are substituted for all components directly under the main control. Further, the stubs are replaced with actual components one by one.

Overview of Integration testing

Integration testing is done to ensure that the integrated system of smaller modules works as per end-user expectations. When you work on an application, many modules interact with each other to accomplish the task a user is trying to perform.

When tested individually in unit testing, it may not uncover any errors. However, when these modules are integrated things such as data flow, API calls, request flow, and much more happen in the back end.

This complex communication network makes the integrated software application prone to errors. This is where integration testing helps us out. It works on the ideology that even if individual modules work perfectly, that might not be the case when they come together.

Integration testing provides two options to get started.

• Big bang testing
• Incremental testing

Big bang integration testing is an approach that tests an application when all its modules have been combined into a single unit. It is similar to testing a complete application as how an end-user would operate but only through test tools, automation testing, etc.

This approach is easier and faster but does not explore all the complicated areas of an application. If the application is small in size, this could work. For large applications, big bang integration testing can compromise the quality of an application by overlooking finer aspects.

Regarding automated testing, don't waste time setting up expensive local test infrastructure. Opt for continuous quality cloud platforms like TestMu AI that provide an online browser farm to run manual and automated tests on over 3000+ real browsers, devices, and OS combinations.

TestMu AI provides automated testing with frameworks such as Selenium, Cypress, Playwright, Puppeteer, Appium, and more. You can also leverage the HyperExecute, an end-to-end test orchestration cloud that enables you to run tests at a blazing speed of up to 70% more than any other traditional cloud grids.

Also, subscribe to TestMu AI YouTube Channel and get detailed tutorials around Selenium automation testing, Cypress testing, and more.

Another approach contradictory to big bang integration testing is incremental integration testing. Here, you can test each module of the application one by one till you reach the central (or main) module. It helps achieve better application quality because of the areas covered in the integration testing phase.

To accomplish this process, you can either work from top to bottom, i.e., start with the main module unit and then test individual sub-modules, or bottom to top, i.e., begin with basic individual sub-modules and then test the complete unit. Both have their advantages, but top down performs better and is the most common approach used in integration testing when scenarios are correct.

Since top down integration testing (also referred to simply as top down testing) is a method to perform incremental testing, it is advantageous for us to explore a few more points in this high-level approach.

Incremental testing is an integration testing approach where you can integrate the software module by module - one by one incrementally. This is a better approach than the big bang because it focuses on each module and smaller combinations. The only thing we need to remember here is to draw the diagram with logical modules only, i.e., the modules that will get connected in the application.

For example, consider this part of the application where we have the following modules:

Here, the central module is Module 1, which we will have to reach ultimately, and the smaller isolated modules are Module 2 and Module 3, and so on. Module 6 may not be directly connected to Module 1, which we need to be cautious about as it may damage the complete testing flow.

The main aim of performing incremental integration testing is to reach an integrated stage (one by one) no matter which way you travel. You can either start from the central module and move towards the end modules colored in green or vice versa. The path you choose determines the approach we take in incremental integration testing, which can be either of the two:

• Top down testing
• Bottom up testing

In incremental testing, you may come across two terminologies: Stub and Drivers.

In top down integration testing, you start from the central module that the end user would use after integrating it with other small modules. But to test this module as an independent entity, we need to have the response from the module it interacts with (the sub-modules), or else we may not be able to identify the correct behavior.

This restriction makes us develop a dummy code that will act on behalf of the original module without actually calling it during testing. Since all we need is the response, just call the dummy code while changing the response as per testing needs every time and test how our current module behaves with those responses. This dummy code is called a stub.

Conventionally, one may find the usage of stubs only applicable when the module is still under development. However, stubs are very important in top down integration testing, even if the developers have built the module. If we start using the developed module, we may not be able to identify whether the bug is in the sub-module or the one we are testing.

Also, please note that the usage of stubs is only applicable to top down integration testing.

The basic construction or principle of a driver is similar to the stub. Still, it is considered different from it due to its usage in different scenarios in testing and working with a whole other segment of return responses.

Consider the same scenarios as above, we are moving from bottom to top this time. Now, we are the smallest module in the first iteration that has no dependency beneath it. But, we may need to have the support of the modules above it to confirm whether the response this module is sending above is correct.

A driver is a dummy code that sends the responses and acknowledgment (primarily not necessarily) to the sub-modules. It helps us identify the behavior of the sub-module independently and quickly.

As of stub, this code can also be used when the upper-level module is either developed or not. However, please note that the usage of drivers is only applicable for bottom up testing.

Top down integration testing is a type of incremental testing where we move from top to down and keep integrating modules as we move ahead. To understand the concept of top down integration testing, we can construct a small example with familiar components used in a web application.

Let’s say we are constructing an application with two modules - a login page, a profile page, and a data record page where all the information regarding the user’s transaction can be seen.

On putting down the system's hierarchy, you may get the following result.

In the top down integration testing approach, we first test the data records, then the data records integrated with Profile Page, and then all three.

To test the data records module, you need a few things from the Profile module, and to get Profile, you need credentials, and the login has been a success. This is achieved through stubs. You create stubs here with the login page module not directly interacting, but the modules above can get the correct response.

In practical situations, the module connections might not be this simple as they are shown here for demonstration purposes. However, the concepts and working conditions remain the same.

Top down integration testing comes with the following benefits for your system.

Top down integration testing demands testing of each individual component along with integrated combinations with stubs that help focus on a single element at once. This enhances the quality of testing and hence the quality of the product.

Stubs help us start testing a module without developing its dependent module. The biggest advantage is that the developers can develop the critical modules first and send them for testing early into the process. It also helps start testing the software early and wrapping things faster.

You can test module systems independently and then, through identification, identify the control process and actual data flow between them. It helps give clarity about the system.

The top down testing may offer one minor disadvantage.

The final software is tested at the end of the cycle. If any bugs were in the integrated software and required disintegrating the modules to develop and test again, it could result in a lot of time consumption. However, if the requirement is to test major defects in the integrated system first, the tester might not face any problems.

Top down integration testing can be done in a couple of ways that resemble the popular tree traversing techniques in data structures.

• Depth-first top down testing
• Breadth-first top down testing

The first type of top down integration testing is depth-first. As its name suggests, we move towards depth and first integrate the modules beneath one another. Once the tree is completely integrated from one side, we again repeat the cycle.

Following the depth-first approach, we get the following integrations in each iteration:

• Iteration 1: Test Module 1
• Iteration 2: Test Module 1 + Module 2
• Iteration 3: Test Module 1 + Module 2 + Module 4

Now we go back up one level, but Module 2 has already been covered, so we go along the second depth.

• Iteration 4: Test Module 1 + Module 2 + Module 4 + Module 5
• Iteration 5: Test Module 1 + Module 2 + Module 4 + Module 5 + Module 3
• Iteration 6: Test Module 1 + Module 2 + Module 4 + Module 5 + Module 3 + Module 6
• Iteration 7: Test Module 1 + Module 2 + Module 4 + Module 5 + Module 3 + Module 6 + Module 7

Every iteration above also implies a regression testing pass: after adding a new module you re-run the tests for all previously integrated modules, not just the new one, to confirm the addition did not break an existing high-level flow. Skipping this is the most common way a top-down suite gives false confidence.

The final result is the integrated application.

As against moving in the direction of depth of the connected tree, breadth-first integration testing focuses on moving horizontally, i.e., along the breadth. The final integrated product remains the same, just the transition to reach there is a little different.

Following the breadth-first approach, we get the following integrations in each iteration.

• Iteration 1: Test Module 1
• Iteration 2: Test Module 1 + Module 2
• Iteration 3: Test Module 1 + Module 2 + Module 3
• Iteration 4: Test Module 1 + Module 2 + Module 3 + Module 4
• Iteration 5: Test Module 1 + Module 2 + Module 3 + Module 4 + Module 5
• Iteration 6: Test Module 1 + Module 2 + Module 3 + Module 4 + Module 5 + Module 6
• Iteration 7: Test Module 1 + Module 2 + Module 3 + Module 4 + Module 5 + Module 6 + Module 7

As with the depth-first sequence, each breadth-first iteration includes a regression testing pass over the modules already integrated, so a newly added module cannot silently break a flow that worked in the previous iteration.

And this sequence can be continued if there exists another level of modules.

The top down integration testing and bottom up integration testing work contrary to each other in almost every aspect. If we could summarize their behaviors and work in a table for quick reference, we would get something as follows.

The Step-by-Step Top-Down Integration Testing Process

Stripped to its core, top-down integration testing is a five-step loop. Each step has one job, and the last one is the step teams skip under deadline pressure, then regret.

• Identify the top-level control modules: Start from the entry points of the architecture, the modules that orchestrate the others. These are tested first because a flaw in the top-level control flow is the most expensive to find late.
• Deploy stubs for unbuilt submodules: Every module the top level calls but that is not ready yet gets a stub, a lightweight fake that returns a canned, predictable response. Stubs let you test the caller before the callee exists.
• Test the high-level modules: Run the top-level modules against the stubs and confirm the control flow, decision logic, and interfaces behave as designed.
• Replace stubs with real submodules, one at a time: Swap a single stub for the real module and re-test. Doing this one at a time is what makes a failure easy to localize; replace five at once and you will not know which broke it.
• Run regression tests after every integration: After each real module is added, re-run the tests for everything already integrated, not just the new module. This is the step that guarantees a new addition has not broken an existing high-level flow, and it is non-negotiable.

Note: The stub-overhead trap: on complex systems, writing realistic stubs can take longer than writing the actual submodules. Before you commit to a fully top-down approach, weigh stub effort against value, and switch to a hybrid (sandwich) approach the moment stub maintenance costs more than it saves. Run your integration suite on TestMu AI free.

Integration testing is one of the critical phases of scrutinizing software after or during its development. It works on the core principle of testing the combined smaller units as a single big piece. For this, we need only two things - know the module dependencies and the steps to move ahead.

Once the module dependency graph is clear, a tester can perform random integrations, called the big bang method, or logically join the modules one at a time, called the incremental method. This guide by Harish Rajora covers one of the types of incremental testing called top down, where we move ahead, starting from the main module and ending with the smallest sub-modules.

Depending on the tester's choice, this can either be achieved by moving depth-wise or breadth-wise. Finally, we conclude this tutorial with a brief comparison of top down testing with bottom up testing that serves as an alternative to a tester and can produce scenarios where testers cannot decide which one to choose.