Contract testing

As explained in Contract Testing in Action

A software testing technique that verifies compatibility between a service provider and its consumers through an agreed contract of requests and responses.

A small API response change can pass a provider’s own pipeline yet break a consumer in production. Contract testing catches this compatibility gap by recording the requests a consumer makes and the responses it expects, then checking that the provider still honors those expectations before deployment. section 1.0 section 1.1

A contract is commonly a JSON artifact describing the two systems and their interactions. Unlike a traditional API integration test, the consumer and provider do not need to run against each other directly: each works through the shared contract. This brings API-level confidence earlier, without relying on a dedicated integrated environment. section 1.1 section 1.6

A renamed response field

A web application expects fullName from a User API. If the API changes that field to name, the systems become incompatible. A verified contract flags the change before release, so the teams can agree on an updated contract or revert the breaking change. A mobile consumer can separately contract for an added favorites field without changing what the web application expects. section 1.2

In consumer-driven contract testing, the workflow separates responsibilities:

• The consumer defines an interaction with a mock provider: a request it will send and the response it needs. Its unit-time test produces a contract and publishes it to a shared broker. section 1.4.1
• The provider downloads the contract, replays the expected request against its real implementation, and compares its actual response with the contracted response. section 1.4.2
• Both consumer and provider tests must run; a generated but unverified contract does not prevent provider breaking changes. section 2.0

Figure 1.5 A contract test between a consumer and a mock data provider

This diagram shows the consumer-side loop: define an interaction against a mock provider, run the consumer test, and generate the shared contract. section 1.4.1

Contract testing fits between unit and integration testing in the test automation pyramid. It complements rather than replaces unit, integration, and end-to-end tests: use it for compatibility expectations, not all provider behavior. Provider business logic and side effects remain functional-test concerns; UI, accessibility, security, and performance need their own testing approaches. section 2.1.5 section 1.3

It is especially useful across microservices or other connected systems, including web or mobile applications and APIs, where full integration or end-to-end suites become slow and difficult to scale. Contracts can run locally and in CI, helping teams find mismatches before they reach shared environments or production. section 1.3 section 2.3.1

Adopt incrementally. Secure buy-in from both sides of an integration, start with one new test or a converted integration test, and prefer a simpler new API over a difficult legacy service. Explain the operational reason—such as flaky integration tests or safer releases—then make progress and outcomes visible. section 2.4.1 section 2.4.2 section 2.4.3

How Contract Testing in Action covers it

How deep it goes

Explains consumer contract generation and provider verification workflows, while deferring detailed implementation and storage approaches.

Examples

Uses a User API, web and mobile consumers, renamed fullName fields, mock providers, shared brokers, and GraphQL services.

What it assumes

Assumes RESTful API and API-testing fundamentals while introducing contract testing from a high-level workflow.

What you can do after

Apply it via Pact to generate consumer contracts, verify providers, publish results, and gate compatible deployments.

How it connects

Connects API integration testing, unit testing, end-to-end testing, microservices, CI pipelines, OpenAPI, and consumer-driven contract testing.

liveBookmanning.com

Read Contract Testing in Action on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Secure APIsContract testing is a testing approach that verifies an API implementation conforms to an agreed API contract or specification.
• 

  liveBookmanning.com
  Infrastructure as Code, Patterns and Practices: With examples in Python and TerraformA contract test verifies that an integration between components conforms to an agreed interface or behavioral contract.
• 

  liveBookmanning.com
  Effective Platform EngineeringA contract test verifies that an implementation conforms to the interface or behavioral contract expected by its consumers.

Compare how 4 books explain contract testing →

Related concepts

• provider-driven contract testingalternative to · Provider-driven contract testing is a contract-testing workflow in which the provider determines or contributes the contract expectations and compares them with consumer expectations.
• Pactincludes · Pact is an open-source contract-testing toolset that verifies interactions between service consumers and providers against consumer-defined expectations.
• contractuses · An API contract is a specification of the operations, data, and behavioral expectations that govern interactions between software components.
• testcontrasts with · A test is a procedure or check that evaluates behavior using specified inputs or evidence against expected results or criteria.
• integration testkind of · An integration test evaluates whether multiple software components, or a component and an external dependency, interact and behave correctly together.
• consumer contractuses · A consumer contract is a machine-readable agreement specifying the interactions and responses a consumer expects from a service provider.

This explainer was generated by Manning's knowledge graph from the text of Contract Testing in Action. The section links point to the parts of the book it draws on.