Integration Testing (Types, Top-Down & Bottom-Up)

What is Integration Testing?

Integration Testing is a sort of testing in which software modules are conceptually connected and tested as a unit. A typical software project is made up of several software modules written by several programmers. The goal of this level of testing is to find flaws in the way various software components interact when they're combined.

Integration testing is concerned with ensuring that data is communicated between various units. As a result, it's also known as "I & T" (Integration and Testing), "String Testing," and "Thread Testing."

  • What is Integration Testing and How Does It Work?

  • What is the purpose of integration testing?

  • Integration Test Case Example

  • Integration Testing Approaches, Strategies, and Methodologies

  • The Big Bang Method

  • A Step-by-Step Approach

  • What is the difference between a stub and a driver?

  • Integration from the bottom up

  • Integration from the top down

  • Sandwich/Hybrid Integration

  • What is Integration Testing and How Does It Work?

  • Integration Test Plans: A Quick Overview

  • Integration Testing Entry and Exit Criteria

  • Integration Testing Best Practices/Guidelines

Purpose of Integration Testing

Despite the fact that each software module is unit tested, faults nevertheless happen for a variety of reasons, including as −

  • In general, a Module is created by a single software developer whose programming logic and understanding may differ from that of other programmers. Integration testing is required to ensure that the software parts function together.

  • There's a good likelihood that the client's requirements may alter throughout module development. These additional needs may not be unit tested, necessitating system integration testing.

  • It's possible that the software modules' interfaces with the database are incorrect.

  • External hardware interfaces, if present, may be incorrect.

  • Exception handling that isn't up to par might cause problems.

Integration Test Case Example

The Integration Test Case is distinct from other test cases in that it focuses primarily on the interfaces and data/information flow across the components. Priority should be given to integrating links over unit functions that have already been tested.

For the following situation, below are some sample integration test cases: The application comprises three modules: 'Login Page,' 'Mailbox,' and 'Delete Emails,' each of which is logically integrated.

The Login Page testing has already been done under Unit Testing, so don't spend too much time on it here. However, look at how it's connected to the Mail Box Page.

Similarly, check the Mail Box's connection with the Delete Mails Module.

Test Case IDTest Case ObjectiveTest Case DescriptionExpected Result
1Verify that the Login and Mailbox modules have an interface relationship.Click the Login button after entering your login credentials.To be directed to the Mail Box.
2Verify that the interface relationship between the Mailbox and the Delete Mails Module is intact.Select the email from the Mailbox and delete it.The Deleted/Trash folder should include the selected emails.

Integration Testing Approaches & Methodologies

Software Engineering offers a number of strategies for doing integration testing, including −

  • Big Bang Approach

  • Incremental Approach

  • Sandwich Approach - Combination of Top-Down and Bottom-Up

The various tactics, how they are implemented, as well as their limits and benefits, are listed below.

Big Bang Experimentation

Big Bang Testing is a technique for integration testing in which all of the components or modules are brought together at the same time and then tested as a single entity. During testing, this integrated collection of components is treated as a single object. The integration procedure will not run unless all of the components in the unit have been finished.


  • It's ideal for tiny systems.


  • It's tough to pinpoint the exact location of a fault.

  • Given the large number of interfaces that must be examined in this method, certain interfaces that must be evaluated may be overlooked.

  • Because integration testing can only begin after "all" of the modules have been defined, the testing team will have less time throughout the testing phase to execute.

  • Due to the fact that all modules are evaluated at the same time, high-risk critical modules are not segregated and examined first. Peripheral modules that deal with user interfaces aren't segregated or prioritized for testing.

Incremental Testing

The Incremental Evaluating technique involves merging two or more modules that are logically connected to one another and then testing the application for correct functionality. The additional connected modules are then progressively integrated, and the procedure is repeated until all logically linked modules have been successfully integrated and tested.

The Incremental Approach is implemented using two alternative methods −

  • Bottom-Up

  • Top Down

Drivers and Stubs

Stubs and Drivers are fake programs used in Integration testing to make the software testing process easier. These programs act as stand-ins for the testing's missing models. They do not implement all of the software module's programming logic, but they do mimic data transfer with the caller module during testing.

  • Stub − This method is invoked by the Module under Test.

  • Driver − This is the program that calls the module that will be tested.

Bottom-up Integrity Checking

Bottom-up The strategy of integration testing is to test the lowest level components first. The tested modules are then utilized to help with the testing of higher-level modules. The process is repeated until all top-level modules have been tested. The next level of modules is generated when the lower level modules have been tested and merged.


  • It is simpler to locate a fault.

  • Unlike the Big-bang strategy, no time is wasted waiting for all modules to be constructed.


  • Critical modules (at the top level of software architecture) that affect the flow of the program are tested last and are more likely to have bugs.

  • It is not feasible to create an early prototype.

Integration Testing from the Top Down

Top-Down Integration Testing is a way of doing integration testing from the top to the bottom of a software system's control flow. To ensure software functioning, higher-level modules are tested first, followed by lower-level modules that are tested and integrated. If certain modules aren't ready, stubs are used to test them.


  • It is simpler to locate a fault.

  • Possibility of getting a prototype early on.

  • Critical Modules are tested first; severe design faults may be discovered and corrected first.


  • Many Stubs are required.

  • Lower-level modules are not thoroughly tested.

Sandwich Testing

Sandwich testing is an approach in which top-level modules are tested with lower-level modules while lower-level components are combined with top-level modules and evaluated as a system. Hybrid Integration Testing is a hybrid technique that combines top-down and bottom-up approaches. Both stubs and drivers are used in this project.

Integration Test Approach

Regardless of the Software testing methodologies (described above), the Integration test approach is as follows −

  • Make a plan for the integration tests.

  • Create the scenarios, cases, and scripts for the tests.

  • Following the execution of the test cases, the flaws are reported.

  • Defect tracking and re-testing

  • Steps 3 and 4 are performed until the Integration is completed successfully.

Integration Test Plans: A Quick Overview

It has the following characteristics −

  • Testing Methodologies/Approaches (as discussed above).

  • Scopes and Exclusions Integration Testing Items

  • Responsibilities and Roles

  • Integration testing has several prerequisites.

  • Environment for testing.

  • Plans for Risk and Mitigation.

Integration Testing Entry and Exit Criteria

In any software development methodology, there are entry and exit criteria for the integration testing phase.

Criteria for Entry

  • Components/Modules that have been unit tested

  • All high-priority bugs have been resolved and closed.

  • All modules must be coded and correctly integrated.

  • Tests of integration Plan, test case, and scenarios must all be approved and recorded.

  • Integration testing requires the creation of a test environment.

Criteria for Exit

  • The Integrated Application was successfully tested.

  • Test Cases that have been completed are documented.

  • All high-priority defects must be repaired and closed before technical documentation and release notes are submitted.

Integration Testing Best Practices/Guidelines

  • Determine the Integration Test Strategy that may be used first, and then create the test cases and data to go with it.

  • Examine the application's architecture and determine the critical modules. These must be tested as soon as possible.

  • Obtain the architectural team's interface designs and write test cases to thoroughly check all of the interfaces. The database interface, as well as any external hardware or software applications, must be thoroughly tested.

  • Following the test cases, the test data is the most important factor.

  • Prior to execution, always have the mock data ready. During the execution of the test cases, do not choose test data.

Integration Testing Challenges

We've covered a lot of ground in terms of how integration testing works and the benefits it provides. Benefits, as is customary, come with some drawbacks. Integration testing might be more difficult than you think due to a number of issues. Here are a few instances of scenarios like this −

  • It's difficult to comprehend the logic of units when there are too many individuals involved in the code development process, each with their own style.

  • Testing can be complicated by a variety of elements (databases, platform, environment, and so on).

  • Integrating two legacy systems, as well as integrating a new system into an existing one, is seldom painless.

  • If multiple teams build distinct systems for integration, they may be incompatible.

  • Choosing the most efficient model might be challenging due to many methodologies and testing combinations.


Integration testing is the second level of the testing hierarchy. It creates a more difficult responsibility for a QA team after unit testing: determining how distinct units function together and whether they work at all.

Integration testing provides for the early detection of faults, lowering the cost of an error and speeding up product delivery. If you neglect this step, you risk overlooking a serious problem that will degrade the user experience or force you to postpone the release date.

Updated on: 01-Dec-2021

1K+ Views

Kickstart Your Career

Get certified by completing the course

Get Started