A platform has many services and many external consumers. Integration tests are slow and flaky. What testing strategy actually gives confidence about compatibility?

Why end-to-end integration tests fail at this job

They require every service running together, which makes them slow, expensive and flaky. Flaky tests are worse than no tests, because they train the team to re-run until green, which discards the signal entirely. They also fail to answer the question that matters — "will my change break a specific consumer?" — since they test one assembled configuration rather than each consumer's actual expectations.

What contract testing provides

Consumer-driven contracts: each consumer declares what it needs from a provider — the fields it reads, the values it depends on, the errors it handles. The provider verifies every consumer's contract in its own pipeline, without either party running the other's code.

That makes compatibility a build-time property rather than an integration-time discovery, and it scales with consumer count in a way that combinatorial integration testing cannot.

What it does and does not catch

Catches: a removed or renamed field, a changed type, a changed error shape, a field that stopped being populated — the overwhelming majority of real integration breakages.

Does not catch: semantic changes where the shape is identical and the meaning is not (a status code that now means something different), performance regressions, or emergent behaviour across several services. Those need different controls — semantic changes need versioning discipline and review, emergent behaviour needs a small number of end-to-end tests on critical journeys.

The practical requirements

• Contracts generated from the consumer's actual tests, not written separately, or they document intent rather than behaviour.
• Provider verification blocking the provider's build, so a break is caught before deployment rather than after.
• A shared contract store with versioning, so a provider knows which consumer versions are in production and can stop verifying retired ones.
• A small end-to-end suite retained for the handful of journeys where the cost of being wrong is highest.

The organisational precondition

Contract testing requires consumers to participate, which is straightforward for internal teams and hard for external ones. For public APIs the equivalent is a recorded traffic replay — running real captured requests against a new version and diffing the responses — which gives similar assurance without requiring anything from the consumer.