Contract testing
Contract testing verifies that two services communicate correctly without requiring both to be deployed for the test. The consumer specifies its expected interactions with the producer (the contract); both sides assert against the contract independently. The dominant tool is Pact, which manages contracts in a broker that both consumer and producer CI pipelines consult.
Contract testing solves the integration-test pain of microservice architectures: end-to-end tests across many services are slow, flaky, and produce ambiguous failures. Contract tests are fast (each side runs in isolation), deterministic (no shared environment), and produce specific failures (the contract violation is named). The trade-off: contract tests don't catch failures in the service's internal logic — that's what unit and integration tests are for. The healthy pattern is a test pyramid: many unit tests, fewer integration tests, contract tests at service boundaries, very few end-to-end tests for critical user journeys. Pairs well with consumer-driven contracts where the consumer's expectations drive the contract.
Related terms
- Integration test
An integration test verifies that multiple components work together correctly — a service hitting a real database, two microservices communicating, a frontend talking to a real API.
- End-to-end testing
End-to-end (E2E) tests exercise an entire user journey across the full stack — UI, API, database, external services — as a real user would.