Skip to content
←Testing

// Testing · 07

Contract Testing

Consumer expectsleads tovia a brokerPact fileleads toProvider verifies

Consumers record what they need; providers prove they still meet it.

How it fits together

Contract Testing structure«client»Consumer testexpects GET /orders/{id}reads totalCents, status«record»Pact fileinteractions as JSONconsumer: BillingPact brokerstores pacts by versionanswers can-i-deployProvider verificationreplays each requestchecks shape and types1 write pact2 publish3 fetch pact4 publish result
createsuses / calls· numbered steps replay in order
  • Consumer test creates Pact file (1 write pact)
  • Pact file uses / calls Pact broker (2 publish)
  • Provider verification uses / calls Pact broker (3 fetch pact)
  • Provider verification uses / calls Pact broker (4 publish result)

Spot it

  • Many end-to-end tests just to check one field
  • A provider change breaks a consumer in production
  • Deploys wait on a shared staging environment

It costs

Every consumer writes tests and every provider runs verification in its build.

Go deeperThe full explanation and what to ask for · 1 min readExpand

The consumer test declares what it needs: the request it sends and the response fields it reads. Running that test against a mock of the provider writes a pact file, a JSON record of the interactions. The provider replays each recorded request against its real code and checks the response still matches. Neither side needs the other running.

The broker stores pact files by version and records verification results. The can-i-deploy check asks whether this version is compatible with what is deployed in each environment. That replaces a shared staging environment where services were tested together and any broken service blocked everyone.

A contract checks shape and agreed behaviour, not business correctness: it shows that a field exists with the type the consumer reads, not that the total is right. Keep a few end-to-end smoke tests for the critical path. When NOT to: a public API with unknown consumers cannot use pacts; publish a specification and compatibility rules instead.

Ask for it

  • consumer-driven contract
  • pact file
  • provider verification
  • contract broker
  • can-i-deploy
  • provider state

Give Orders a consumer-driven contract with Billing: Billing records that GET /orders/{id} returns 200 with an integer totalCents and a status of Open or Paid. Publish the pact to the broker from Billing CI, make Orders verify it in its pipeline, and gate both deploys on can-i-deploy.

Connects to