TerminologyIntermediate4-6 min reference
Contract Testing Terms
Contract testing verifies that two services agree on the messages they exchange — without spinning up both in a slow end-to-end run. It catches integration breakage at unit-test speed. This sheet defines the vocabulary and the decision of when to reach for it; for the Pact toolchain specifically, see the Pact sheet.
Vocabulary
| Term | Means |
|---|---|
| Consumer | The service that calls the API |
| Provider | The service that serves the API |
| Contract / Pact | The agreed request/response expectations |
| Consumer-driven | The consumer's expectations define the contract |
| Interaction | One request/response pair in the contract |
| Provider verification | Replaying the contract against the real provider |
| Broker | Central store that shares contracts between teams |
can-i-deploy | Broker check: is this version safe to release? |
| Pending / WIP pacts | New contracts that don't fail the provider yet |
Contract vs E2E vs schema
| Contract test | E2E test | Schema validation | |
|---|---|---|---|
| Runs both services? | No (mocked) | Yes | No |
| Speed | Fast | Slow | Fast |
| Catches | Integration mismatch | Real-world flow | Shape/type drift |
| Owned by | Consumer + provider | QA | Either |
When to use
- Many services / teams evolving APIs independently → contract tests catch breakage before deploy.
- You want integration confidence without a full E2E environment.
- Not a replacement for E2E on critical user journeys, or for functional/business-logic testing.
Common mistakes
- Treating contract tests as E2E — they verify the message shape/agreement, not behaviour.
- Provider-driven contracts that ignore what consumers actually need.
- No broker, so contracts go stale and
can-i-deploycan't gate releases. - Putting business assertions in the contract instead of in functional tests.
// Related resources