Glossary · Testing fundamentals
Integration test
Also called: integration tests, integration testing
Definition
A test that checks whether two or more components, such as a service and its database or two APIs, work correctly together through their real interfaces.
An integration test verifies the connections between components rather than the logic inside one. It uses real implementations on at least one boundary: a repository against a real database, a service calling another service’s API, a message producer and its consumer. These are the tests that catch wrong SQL, bad serialization, missing configuration and mismatched contracts, all of which unit tests with mocks would miss.
Example
An OrderRepository is unit-tested with mocks, and those tests pass. The integration test runs it against a real PostgreSQL instance started in a container:
- Start PostgreSQL with Testcontainers and apply the schema migrations.
- Save an order with three line items through the repository.
- Load it back by ID and assert the totals and line items match.
- Query orders by date range and assert the boundaries are inclusive.
Run against a real database, this test can reveal a column-name typo, a migration that was never applied, a time-zone conversion error, or a query that works in an in-memory database but not in PostgreSQL.
Integration vs unit vs end-to-end
| Unit | Integration | End-to-end | |
|---|---|---|---|
| Scope | One function or class | A few components and their interfaces | The whole system, as a user |
| Dependencies | Replaced with doubles | Real at the boundary under test | All real |
| Speed | Milliseconds | Seconds | Seconds to minutes |
| A failure points to | A specific piece of logic | A specific interface | Somewhere in the system |
Approaches
- Narrow integration tests check one boundary at a time (service plus database) with everything else stubbed. They are fast and precise, and most teams want many of them.
- Broad integration tests start several real services together. They give more confidence but are slower and harder to diagnose.
- Classic textbooks also describe big-bang, top-down and bottom-up integration, which describe the order in which modules are combined. In interviews it helps to know the terms, but modern teams mostly integrate continuously.
Common mistakes
- Sharing one long-lived database between tests and developers, which makes results depend on leftover data. Give each run a clean, disposable instance.
- Mocking the very boundary you meant to test, which turns an integration test back into a unit test.