Example usage
After the login module and the order module of an application are individually tested, integration testing verifies their interaction: a user logs in and places an order, and the order module correctly receives the authenticated user’s identity. Test data and expected results cover the interfaces — API contracts, database connections, and shared data formats. The goal is to expose defects in the interfaces and in the interactions between integrated components or systems.
FAQ
What is the difference between integration testing and system testing? Integration testing focuses on interfaces and interactions between integrated components or systems. System testing tests the complete, fully integrated system against its requirements. Integration comes first; system testing follows once everything is integrated.
What is a top-down or bottom-up approach? These are integration strategies. Top-down starts with the top-level modules and uses stubs for lower modules; bottom-up starts with lower modules and uses drivers. Both aim to expose interface defects progressively.
Do integration tests need real interfaces? Ideally yes, but stubs and drivers are used when the real modules are not yet available. The risk is that defects hidden by the substitute only surface during system testing.
Why do interface defects happen so often? Because components are often developed in parallel, and assumptions about data formats, error handling, and timing are rarely documented precisely. Integration testing makes those assumptions visible.
Related terms
- system testing — testing the complete integrated system
- component testing — testing individual components before integration
- regression testing — re-verifying unchanged behavior after integration
- test level — the lifecycle stage integration testing belongs to
- test type — integration testing grouped by objective
- integration — combining components into a working system
