Integration testing

Integration testing confirms that the interfaces between modules—both logical and physical—function as designed. It is a critical step in the V-model, where each development phase corresponds to a testing phase; integration testing is paired with the high-level design phase and is often performed by a separate test team or by developers working on adjacent modules. Defects caught at this stage are typically less expensive to fix than those discovered during system testing or production. Typical integration issues include parameter mismatches, incompatible data structures, timing problems, and violations of pre- or post-conditions.¹ The process also validates that the system fulfills the architectural requirements laid out in the design document.

Several integration strategies exist, each with trade-offs. The Big Bang approach assembles all modules at once, which is quick but makes fault isolation difficult. Top-down integration starts with the top-level control module and uses stubs to simulate lower-level modules, allowing early validation of system logic. Bottom-up integration begins with low-level modules and uses drivers to simulate higher-level callers, enabling early testing of core functionality. The Sandwich (or hybrid) approach combines top-down and bottom-up, reducing the number of stubs and drivers needed. A lesser-used but effective strategy is Backbone integration, which first integrates a minimal skeleton of the system and then adds modules incrementally, useful for large distributed systems.² In modern agile and DevOps environments, continuous integration (CI) pipelines automate builds and run integration tests frequently, often adopting a continuous integration testing approach that merges code changes multiple times a day.

A key challenge in integration testing is managing dependencies: stubs and drivers must be created for incomplete modules, and their quality can affect test validity. Interface mismatches, such as incorrect data types or missing error handling, are common. To mitigate these, practitioners recommend using interface contracts (e.g., pre- and post-conditions) and automated mock frameworks. Another challenge is test environment setup—multiple teams may need coordinated access to shared databases, services, or hardware. Best practices include planning integration test cases early during architectural design, maintaining a regression test suite for each integration level, and establishing clear criteria for when integration is complete, such as all planned integration tests passing with no critical or high-severity defects.³ In safety-critical domains like avionics, standards such as DO-178C require coverage of all data and control coupling between modules, imposing rigorous integration testing obligations.⁴

The term “integration testing” was popularized by Glenford J. Myers in his 1979 book The Art of Software Testing, where he distinguished it from unit and system testing. Few realize that integration testing is not limited to functional correctness; it also covers non-functional aspects such as performance, security, and reliability at the integration level. For example, a security integration test might verify that authentication tokens are correctly passed between a front-end and a back-end service. Another niche is risk-based integration testing, where the test sequence is prioritized by the criticality of interfaces identified in a failure modes and effects analysis (FMEA). Additionally, integration testing of legacy systems often requires “wrapper” modules to simulate modern interfaces, a technique known as strangler fig integration. The discipline also has a formal theoretical foundation: the concept of “integration test coverage” can be measured by coupling metrics such as McCabe’s cyclomatic complexity of the integrated system.²

Stub

A minimal implementation of a called module used during top-down integration testing to simulate behavior.

Driver

A test harness that calls the module under test for bottom-up integration, simulating a higher-level component.

Continuous Integration (CI)

A development practice where code changes are merged frequently and automatically tested, including integration tests.

DO-178C

The US Federal Aviation Administration (FAA) standard for software in airborne systems, requiring specific integration and coupling testing.