Differences Between Top Down Testing Vs Bottom Up Testing
Effective software testing heavily on incremental integration testing. In this approach, testing begins with the integration of multiple modules that are logically related, followed by functionality tests.
This test ensures that the integrated units work properly as a unit. However, there are two approaches to incremental integration testing. You can execute an incremental integration test by following a top down or bottom up approach.
As they are both incremental integration techniques, it’s easy to get confused between top down testing vs bottom up testing. Despite the fact that both tests detect integration flaws, they do follow significantly different techniques.
Additionally, if you don’t choose the method suitable for your specific project, you might not get the desired results. As a result, understanding the differences between them is critical.
We’ve covered everything you need to know about top down and bottom up testing in this article. So, let’s get started.
What Is Integration Testing?
Integration testing also known as I & T is a software testing technique where different software modules or components are integrated and tested as a single unit.
Software projects consist of many software modules. These modules are often coded by different programmers.
Integration testing verifies if the different modules perform as they should when integrated together.
Customer requirements may change at any point during the software development life cycle. These requirement modifications may not reach the developers correctly.
Moreover, the new changes might not be unit tested either hence Integration testing is required to ensure that the software works properly.
It mainly focuses on checking communication between different modules. If integration testing is skipped, many errors may go undetected. Such errors can result in integration failures which are time-consuming and expensive to fix once the software has been released.
Objective Of Integration Testing
Integration testing is a crucial part of the software development industry. Especially since client requirements are extremely dynamic and deadlines are limited.
As a result, ensuring software quality in a limited time becomes a difficult task for the QA team. The main objectives of integration testing are:
- Ensuring that software modules function properly after integration
- Verify that software features follow client requirements
- Assess all the functional and non-functional features for efficiency
- Check that related modules are synchronized
- Expose interface errors that may arise after integration
- Test communication between separate modules
- Pinpoint weak spots in the software architecture
- Ensure proper fixes for all the exception handling errors
- Prevent errors from leaking to high-level tests
What Is Top-down Testing?
In top down testing technique, high-level modules are tested first, and then lower-level modules are tested. High-level modules are also known as main modules, whereas low-level modules are referred to as submodules.
If the submodule is not ready for integration yet, temporary modules called STUB are used for simulating the real submodule. The main modules are also integrated first and submodules are integrated subsequently to check if the software functionality works properly.
The term “top down” refers to the fact that testing is done from top to bottom, as in from main modules to submodules following the control flow of the software.
Furthermore, while integrating submodules, we must ensure that the module we are integrating is a child of the main module. This testing is primarily performed on software written in a procedure or structure-oriented language.
The prime objective of top-down integration testing is to uncover key design defects early on since the main modules are tested first.
Advantages And Disadvantages Of Top-down Testing
- Critical Modules are tested on priority
- Early detection & fixing of major design defects
- Fault localization becomes easier
- Allows creation of early prototype
- Early prototype makes test case creation easier
- Many stubs need to be produced
- Creating stubs for intricate features may become complicated
- Representing test cases in stubs can be difficult
- Observation of test output is more difficult
- Lower-level modules are insufficiently tested
What Is Bottom Up Testing?
In the bottom up testing technique, testing is done from the submodule to the main module. The modules will be added from the bottom to the top, and the data flow will be tested in a similar manner.
Meaning lower-level modules are tested & integrated first to execute certain software functions. If the higher-level module isn’t constructed yet, a temporary program called DRIVERS is used for mimicking the main module. This driver configures test case input and output in order to test the lower modules.
These tested modules are then utilized to help with testing of higher-level modules. While following this upward testing direction, drivers are eliminated as main modules get developed completely.
Here, the top-level modules are tested at the very last stage. As a result, testers get less time to test the critical modules which can result in major errors being left in the code.
This integration testing is done on applications developed using object-oriented languages.
Advantages And Disadvantages Of Bottom Up Testing
- Detects major flaws that occur at the lower level modules
- Testing can start without waiting for all units to be completed
- Easy to create test conditions
- Test result observation is easier
- Driver modules have to be produced
- Early prototype can not be generated
- Critical modules at top get tested inadequately
- Main modules may remain prone to defects
Key Differences Between Top-down And Bottom-up Integration Testing
Learning the key differences between top down testing vs bottom up testing will enable QA testers to make well-informed choices as to which type of integration testing technique will be suitable for their projects.
First of all, the top down approach utilizes stubs as a temporary replacement for lower modules whereas the bottom up approach uses drivers to simulate the higher-level modules.
The main or top modules are given the most importance in the top down approach. The top modules are tested first and through these main modules, other submodules are called.
On the contrary, higher emphasis is given to the lower modules in the bottom-up approach. Here, submodules are created, tested, and integrated first.
Another major distinction is that top down technique examines the risk by collecting the internal operational failure impacts, but the bottom-up method evaluates individual processes risk with models’ support.
Moreover, top-down testing goes from major to minor components, whereas bottom-up testing goes from small to significant modules.
Lastly, top down testing is simpler in complexity & data intensity as compared to bottom up testing.
|Top Down Integration Testing||Bottom Up Integration Testing|
In top down Integration, testing takes place from top to bottom means system integration begins with main modules.
In bottom up integration, testing takes place from bottom to top means system integration begins with lower level or submodules.
If the invoked submodule hasn't been developed yet, stubs are used for temporarily simulating that submodule.
If the main module hasn't been developed yet, drivers are used for temporarily simulating that main module.
Higher level modules are tested & integrated first and then lower level modules are tested & integrated.
Lower level modules are tested & integrated first and then higher level modules are tested & integrated.
Main modules are created first and then submodules are called from it.
Different smaller modules are developed and then integrated with the main module.
Control flows from top to bottom.
Control flows from bottom to top.
This approach is advantageous if the significant bugs occur in the top modules.
This approach is advantageous if the crucial defects occur in the lower modules.
Mainly implemented in structure or procedure oriented programming languages.
Mainly implemented in object oriented programming languages.
Testing complexity is low.
Testing complexity is high and data intensive.
Stubs and Drivers
It is always a good idea to develop and test software in “pieces”. But, it may seem impossible because it is hard to imagine how you can test one “piece” if the other “pieces” that it uses have not yet been developed (and vice versa).
A software application is made up of a number of ‘Units’, where output of one ‘Unit’ goes as an ‘Input’ of another Unit. e.g. A ‘Sales Order Printing’ program takes a ‘Sales Order’ as an input, which is actually an output of ‘Sales Order Creation’ program.
Due to such interfaces, independent testing of a Unit becomes impossible. But that is what we want to do; we want to test a Unit in isolation! So here we use ‘Stub’ and ‘Driver.
A ‘Driver’ is a piece of software that drives (invokes) the Unit being tested. A driver creates necessary ‘Inputs’ required for the Unit and then invokes the Unit.
Driver passes test cases to another piece of code. Test Harness or a test driver is supporting code and data used to provide an environment for testing part of a system in isolation. It can be called as as a software module which is used to invoke a module under test and provide test inputs, control and, monitor execution, and report test results or most simplistically a line of code that calls a method and passes that method a value.
For example, if you wanted to move a fighter on the game, the driver code would bemoveFighter(Fighter, LocationX, LocationY);
This driver code would likely be called from the main method. A white-box test case would execute this driver line of code and check “fighter.getPosition()” to make sure the player is now on the expected cell on the board.
A Unit may reference another Unit in its logic. A ‘Stub’ takes place of such subordinate unit during the Unit Testing.
A ‘Stub’ is a piece of software that works similar to a unit which is referenced by the Unit being tested, but it is much simpler that the actual unit. A Stub works as a ‘Stand-in’ for the subordinate unit and provides the minimum required behavior for that unit. A Stub is a dummy procedure, module or unit that stands in for an unfinished portion of a system.
Four basic types of Stubs for Top-Down Testing are:
– Display a trace message
– Display parameter value(s)
– Return a value from a table
– Return table value selected by parameter
A stub is a computer program which is used as a substitute for the body of a software module that is or will be defined elsewhere or a dummy component or object used to simulate the behavior of a real component until that component has been developed.
For example, if the movefighter method has not been written yet, a stub such as the one below might be used temporarily – which moves any player to position 1.
public void moveFighter(Fighter player, int LocationX, int LocationY)
Ultimately, the dummy method would be completed with the proper program logic. However, developing the stub allows the programmer to call a method in the code being developed, even if the method does not yet have the desired behavior.
Programmer needs to create such ‘Drivers’ and ‘Stubs’ for carrying out Unit Testing.
Both the Driver and the Stub are kept at a minimum level of complexity, so that they do not induce any errors while testing the Unit in question.
Stubs and drivers are often viewed as throwaway code. However, they do not have to be thrown away: Stubs can be “filled in” to form the actual method. Drivers can become automated test cases.
Example – For Unit Testing of ‘Sales Order Printing’ program, a ‘Driver’ program will have the code which will create Sales Order records using hardcoded data and then call ‘Sales Order Printing’ program. Suppose this printing program uses another unit which calculates Sales discounts by some complex calculations. Then call to this unit will be replaced by a ‘Stub’, which will simply return fix discount data.
Frequently Asked Questions
What Are The Basic Stubs For Top Down Testing?
There are 4 basic types of stubs used for top down testing. They are: Display trace messages, Display parameter values, Return table values, Return specific table values based on parameter.
Integration testing is of utmost importance for ensuring good-quality defect-free software. For choosing the right integration testing technique, you must know the differences between top down testing vs bottom up testing.
In this article, we have discussed everything you need to know about top down and bottom up integration testing along with a comparison chart between the two.
With the help of this knowledge, you’ll be able to make an informed decision between these two testing techniques. Both techniques come with pros and cons. So, based on your testing project and resources, choose the one that offers the most benefits.