API Contract Testing: Preventing Integration Breakage
API contract testing verifies that an API provider and its consumers agree on the shape of API requests and responses — catching breaking changes before they reach production and break integrations. It is a more targeted and efficient alternative to full end-to-end integration testing for validating API compatibility.
The Contract Testing Problem
When a backend team changes an API response shape — renaming a field, changing a type, removing a property — consumer applications break. Without contract testing, this is discovered in production or in lengthy integration test suites. Contract testing makes this class of bug impossible to miss before deployment.
Consumer-Driven Contract Testing
The consumer defines the contract — what request it makes and what response fields it expects. The provider verifies it can satisfy that contract. This is the correct direction: the consumer's needs drive the contract, not the provider's interpretation of what consumers need.
Pact
Pact is the leading tool for consumer-driven contract testing. Consumers write Pact tests that define their expectations. The resulting Pact file is shared with the provider (via a Pact Broker). The provider runs its own tests to verify it satisfies all consumer contracts. The CI pipeline blocks provider deployment if any consumer contract is broken.
OpenAPI Schema Validation
Simpler than Pact but less powerful: validate that API responses conform to the published OpenAPI schema. This catches structural changes without consumer-specific contracts. Dredd is a tool that runs tests against an OpenAPI spec automatically. A good baseline if consumer-driven contracts are too much overhead.