Where should the boundary of an integration test sit, and what is the common mistake?

Where the boundary should sit

At the edge of the thing you own, with its real dependencies inside and everything else stubbed.

For a service, that means: the service's own code and its own database — real, because the database's behaviour is part of what is being tested — with every external service, third-party API and message broker stubbed.

This gives determinism, speed and clear ownership: the test fails only for reasons within the team's control.

The common mistake

Including real external dependencies, "for realism".

It produces a test that fails when someone else deploys, is slow because it waits on a network, requires coordinated test data across teams, and gives a failure the team cannot diagnose or fix. Realism is bought with determinism, and determinism is what makes a test useful.

The other consequence is that such a test cannot be run locally, which means developers do not run it, which means it catches problems late.

What replaces the realism

Contract tests. The consumer states what it needs from the provider; the provider verifies every consumer's expectations in its own pipeline. That is the assurance an integration test with a live dependency was attempting to provide, delivered deterministically and with clear ownership.

The database question

Use the real database engine, not an in-memory substitute. Query behaviour, transaction semantics, constraint enforcement and type coercion differ, and a test against a substitute verifies behaviour the production system does not have. Containerised databases make this cheap enough that the substitute is rarely justified.

What remains genuinely end-to-end

A small number of critical journeys, run in a realistic environment — not to catch interface breaks, which contracts handle, but to catch integration assumptions no contract expresses: ordering, timing, configuration and data-state dependencies.

The shape is a large fast contract layer plus a deliberately tiny end-to-end layer, rather than the inverted pyramid most organisations accumulate.