Integration testing
Also known as Integration tests
Definition
Integration testing checks whether two or more software components work together through their real or representative interfaces. It focuses on interactions such as application-to-database queries, service calls, message publishing, or framework configuration.
Definition
Integration testing examines the seams between components rather than only the logic inside one component. The scope can be narrow, such as an application talking to a real database, or broader, such as several services communicating through an API or queue. The defining question is whether the participants exchange data and handle behavior as expected.
What integration tests reveal
These tests can expose mismatched schemas, incorrect serialization, authentication problems, transaction behavior, timing assumptions, and configuration errors. They are especially useful where a unit test's stubs would hide a failure in a real adapter or protocol. Teams should state which dependencies are real, which are controlled, and which behavior the test is intended to prove.
Integration tests usually cost more to run and maintain than unit tests. A database may need isolated data, a service may need a stable environment, and failures may require more diagnosis. Keeping the boundary explicit and the setup repeatable makes the resulting feedback more trustworthy.
Example
Consider an order service that writes an order to a database and publishes an OrderCreated message. An integration test can start with an isolated database, submit an order through the service boundary, verify the stored record, and consume the message to check its required fields.
A unit test could verify the order calculation without either dependency. The integration test answers a different question: whether the application, persistence mapping, and message producer agree on the interaction.
Limitations
Integration tests cannot cover every system path or prove that a complete user journey is correct. They can also become slow and brittle when they include too many unrelated services. Use focused integration tests for important boundaries, and combine them with unit tests and broader system checks. When a third-party dependency is unavailable, a contract or representative test may be useful, but it should be labeled honestly as a substitute.
How this relates to Weave
Weave helps teams examine the delivery context around integration testing by connecting changes, checks, review activity, rework, and deployment outcomes. This can help identify whether integration suites create long feedback queues, fail intermittently, or catch defects before release. Weave does not replace the test runner or certify an interface contract, so the integration environment and its test results remain the evidence for compatibility.
Explore Engineering intelligence