ꦲꦏ꧀ꦱꦫ
Back to stories
<QA/>
QATestingAPIQA

Contract Testing for APIs: What QA Should Know

PublishedUpdated AKSR
Share by

Contract Testing for APIs: What QA Should Know

Contract testing checks that API consumer and provider agree on the request/response format (the "contract"). It catches breaking changes before integration. This post introduces contract testing from a QA perspective: what it is and when it helps.

What is contract testing?

  • Contract: The agreed shape of requests and responses between consumer (e.g. frontend, another service) and provider (e.g. API).
  • Consumer contract: "When I send this request, I expect this response." Consumer test generates a contract (e.g. Pact file).
  • Provider contract: "Given this request, I respond like this." Provider test verifies the provider satisfies the consumer's contract.
  • Goal: If the provider changes the API in a way that breaks the consumer, the provider's contract tests fail. No need to run full integration to catch it.

Contract vs integration testing

  • Integration test: Consumer and provider (or mocks) run together; real or realistic network. Broader but slower and more fragile.
  • Contract test: Consumer and provider tested separately against the same contract. Faster and more focused on compatibility; does not replace full integration for end-to-end behavior.

Use both: contract tests for compatibility and fast feedback; integration tests for full flow.

When QA can contribute

  • Define expectations: QA can help define or review the contract (request/response shape) from a testing and product perspective.
  • Consumer tests: If QA owns or contributes to consumer-side tests, they can help generate or maintain consumer contracts (e.g. Pact).
  • Provider verification: QA can run or maintain provider-side contract verification (e.g. Pact provider tests) in CI.
  • Documentation: Contracts (e.g. OpenAPI, Pact) double as documentation; QA can use them for manual and automated API testing.

Summary

  • Contract testing = consumer and provider agree on request/response; consumer generates contract, provider verifies it.
  • It catches breaking API changes early; use it alongside integration tests for full flow.
  • QA can contribute by defining expectations, maintaining consumer or provider contract tests, and using contracts for API test design.