A payment module can pass every unit test. An order module can pass every unit test. Put them together, and the payment confirmation arrives in a format the order module doesn't expect, and the whole flow silently fails. Neither component was "wrong" in isolation. The problem lives entirely in the space between them, which is exactly where integration testing operates.
What integration testing actually checks
Integration testing verifies that separate modules, services, or systems work correctly when combined, focusing specifically on the interfaces and data flow between them, not the internal logic of each piece.
- Data flow between components. Does data leaving one module arrive in the shape the next module expects?
- API contracts between services. Does Service A call Service B correctly, and does Service B respond in a way Service A can actually use?
- Database interactions. Does the application layer read and write data consistently with what the database schema actually supports?
- Third-party integrations. Does your system correctly handle the real (not idealized) behavior of the external services it depends on?
Two common approaches
- Big bang integration, combining all components at once and testing the fully integrated system. Fast to set up, but when something fails, isolating the cause among many newly-combined pieces is painful.
- Incremental integration, combining and testing components gradually, one connection at a time. Slower to set up, but failures are far easier to trace to their source.
Most mature teams lean incremental, especially as systems grow more complex, because the debugging cost of big bang integration scales badly with system size.
Integration testing isn't about re-verifying that each component works. It's about verifying they agree with each other, on data format, on timing, on error handling, which unit tests structurally can't tell you.
Why this layer gets under-tested
Integration testing sits in an awkward gap: developers often feel it's QA's job, QA often assumes developers cover it through unit and API tests, and it ends up covered less thoroughly than either layer alone. This gap is precisely where a surprising number of production incidents originate, not broken components, but components that were never properly tested together.
Where we focus integration testing effort
We prioritize integration points with the highest blast radius if they fail: payment processing, authentication handoffs between services, and any point where your system depends on a third party's actual (not documented) behavior.
If your architecture has grown more interconnected than your integration test coverage has kept up with, QA Solucity's API testing and QA strategy services help close that gap. Get in touch to talk through your system's integration points.
