Integration test: Big bang, Bottom up, Top down and Sandwich testing strategies
The integration test is the process of verifying the interaction between software components. Classic top-down or bottom-up integration testing strategies are used with traditional, hierarchically structured software. The modern strategies of systematic integration are instead guided by the architecture, ie the software components and subsystems are integrated on the basis of the identified functionalities. The integration level test is a continuous activity. Except for the cases of very small and simple software, the systematic and incremental integration testing strategies are to be preferred over the strategy of putting all the components together at the same time, in what is called “big bang” testing. Starting from a hierarchically organized architecture, the integrations can be carried out with a top-down or bottom-up or mixed approach.
Integration testing detects bugs that were not detected during unit testing, focusing on a set of components that you integrate.
Two or more components are integrated and analyzed, and when bugs are detected new components can be added to fix the bugs. Developing test stubs and test drivers for a systematic integration test is time-consuming.
Integration tests verify how two (or more) units work together. Integration tests require:
- the construction of the system starting from its components and the testing of the resulting system to discover problems arising from the interaction between the various components.
- the identification of groups of components that realize the various functions of the system and their integration through components that make them work together.
Testing strategies
The order in which the components are integrated can influence the effort required for integration. The order in which the subsystems are selected for testing and integration determines the testing strategy:
- Big bang integration (Non-incremental)
- Bottom up integration
- Top down integration
- Sandwich testing
- Variations: each of these strategies was originally conceived for a hierarchical decomposition of the system. Each component belongs to a hierarchy of layers, sorted according to the “Call” association.
BIG-BANG approach
The components are first tested individually and then tested together as a single system. Although it is simple to make, it is expensive: if a test reveals a failure, it is impossible to distinguish the failures in the interfaces from the failures within the components.
BOTTOM-UP approach
The subsystems in the bottom layer of the hierarchy are individually tested. The following subsystems to be tested are those that “call” the subsystems tested previously. This process is repeated until all subsystems are tested. The test drivers are used to simulate the “top” layer components that have not yet been integrated.
Pros and cons of the BOTTOM-UP approach
It is not ideal for functionally decomposed systems:
- Test the most important subsystems at the end
- Useful for integrating the following systems: Object-oriented systems, real-time systems and systems with stringent performance requirements No stub tests are required.
Interfaces errors can be identified more easily if the high-level component violates the assumptions made by the low-level component, this can be more easily identified by the developers.
TOP-DOWN approach
This approach tests the top layers or the control subsystems first. It then combines all the subsystems that are called by the tested subsystems and then tests the resulting collection of subsystems. Iter this activity until all systems are integrated and tested. The stub tests are used to simulate the components of the bottom layers that have not yet been integrated.
Test cases can be defined in terms of system functionality.
Advantage: starting from the user interface
Disadvantages:
- Writing stubs can be difficult: stubs must allow all possible conditions to be tested.
- It is possible that a large number of stubs are required, especially if the lower level of the system contains many methods,
A solution to avoid many stubs: modified top-down
- Test each layer of decomposition individually before merging layers
- Disadvantage: both stub and test driver tests are required
SANDWICH approach
Combine top-down strategy with bottom-up strategy The system is seen as having 3 layers:
- A target layer
- A layer above the target
- A layer below the target
Testing converges to the target layer. How to select the target layer if there are more than 3 layers? You can try to minimize the number of stubs and drivers.
Pros and cons of the SANDWICH approach
Top and bottom layer tests can be performed in parallel. Problem: individual subsystems are not tested before integration.
