On a microservices platform, the scariest bugs aren't inside a service — they're in the gaps between services. One team renames a field, another team's parser silently breaks. Contract testing is how you catch that early.
The Problem It Solves
End-to-end integration tests across many services are slow, flaky, and hard to debug. When they fail, you don't know which service moved. Contract tests isolate the agreement between two services into a fast, focused check.
Consumer-Driven Contracts
The consumer defines what it needs from the provider:
The order-service expects GET /users/{id} to return:
- id (number)
- email (string)
- status (one of: active, suspended)
That expectation becomes a contract. The provider then runs the contract against itself in CI. If someone renames status to accountStatus, the provider's build fails — before the change ever reaches the consumer.
What a Contract Is Not
A contract is not a full functional test. It checks the shape and rules of the interaction, not business logic. It answers "do we still speak the same language?" not "is the answer correct?"
Where It Fits in the Pyramid
| Layer | Speed | Catches |
| Unit | Fast | Logic inside a service |
| Contract | Fast | Interface mismatches between services |
| E2E | Slow | Whole-system behavior |
Contract tests give you a lot of the confidence of integration tests at the speed of unit tests. You still need a few real E2E tests on top — just far fewer.
The Cultural Part
Contract testing only works if both teams treat a broken contract as a blocker, not a suggestion. The first time a provider ships a breaking change anyway, the contracts become decoration. The tooling is easy; the agreement to honor it is the actual work.