A platform with many services finds that integration tests are slow and flaky, yet removing them causes breakages between services. What testing approach resolves this, and what does it require organisationally?
Show the full answer Hide the answer
Why end-to-end integration tests fail at this scale
They are slow, requiring many services to be deployed and healthy.
They are flaky, because failure can come from any service, the environment, test data, or timing — and a suite that fails for unrelated reasons trains everyone to re-run it rather than investigate.
They give unclear ownership. A failure in a shared suite belongs to nobody, so it is nobody's priority.
They scale badly. The number of interaction paths grows combinatorially while the suite's value grows linearly.
They test too late. A break is found after both services are deployed together, rather than when the change was made.
How consumer-driven contracts work
Each consumer writes tests describing what it needs from a provider: this request produces a response with these fields of these types. Those expectations are published to a shared broker.
The provider's pipeline verifies every published contract on every build. A change violating any consumer's expectation fails the provider's build, before merge, with a clear message naming the affected consumer.
The crucial properties:
- Fast and deterministic — no environment, no other services running.
- Ownership is unambiguous — the failing build belongs to the team that made the change.
- It tests the actual constraint. What matters is not that all services work together in a lab, but that no service breaks what its consumers depend on.
- It documents real usage. The set of contracts tells the provider exactly which fields are used, which is precisely the information needed for safe deprecation.
What it requires organisationally
This is where adoption succeeds or fails.
Consumers must write and maintain contracts. This is work for the consumer that benefits the provider, which is a misaligned incentive unless leadership treats it as the standard.
Providers must not ignore failures. A red contract check that gets overridden makes the whole scheme theatre.
A broker to operate, with contract versioning and a clear rule about which consumer versions must pass.
Discipline about scope. Contracts test the interface, not business logic. Teams that put behavioural assertions into contracts produce a brittle, unmaintainable suite and conclude the technique does not work.
What still needs end-to-end testing
A small number of critical user journeys — sign-up, checkout, the primary workflow — tested 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.