Which three points require evidence before adoption?

Consumer expectation, Provider verification, Version matrix.

Standalone conceptTesting approachChapter II · Communication · Building block 2 of 23

Consumer-Driven Contract Testing

Consumer-driven contract testing lets consumers publish executable expectations that the provider verifies against its current implementation in the build pipeline.

By Michael Meierhoff · Meierhoff Systems

Consumer expectationMinimally describes the interaction actually used.
Provider verificationRuns all published expectations against the provider implementation.
Version matrixConnects contract, consumer, provider, and environment.

Context

Why this is important

The approach tests observable interactions between known participants; it complements provider schemas, business integration tests, and runtime observability.

The distributed extension in the shop scenario is hypothetical; the current shop remains a modular monolith with seven modules and one shared database.

Shop example · Mapping

Consumer-Driven Contract Testing: decision boundaries

The current shop remains a modular monolith with seven modules. Order consumes Payment’s internal contract for authorization status and rejection reason. The Order team publishes a contract with success and rejection examples; Payment verifies it in the pipeline for every change. For a hypothetical later service split, contract, provider version, and deployment environment are published together. The team deliberately changes a field that became optional and checks that only expectations actually in use block release.

This is how you read the picture

Consumer expectation Relevant fields and errors
Provider verification Pipeline gate
Version matrix Release with concrete versions

Consumer-Driven Contract Testing: decision boundaries
Comparison	Aspect	Sound use	Limit
Schema validation	Checks full provider contract shape	Broad syntactic coverage	Does not prove real consumer use
Consumer contract	Checks used examples and errors	Early compatibility signal	Only known published expectations
End-to-end test	Tests running integration	High realism	Slower and harder to isolate

The matrix connects benefit, ownership, and boundary.

Benefits & limitations

Helps if:

Broad syntactic coverage
Early compatibility signal
High realism

Boundaries

Does not prove real consumer use
Only known published expectations
Slower and harder to isolate

In practice

Choose a real payment interface and record only the fields, status codes, and error shapes that Order actually evaluates. Create a minimal success and rejection contract from them.
Change one used provider field incompatibly and one unused field compatibly. Run provider verification and confirm that only the real consumer expectation blocks release.
Build a version matrix of contract, consumer, provider, and target environment. Simulate an old consumer and use published verification results to decide which provider version can be deployed safely.

Read the detailed explanation

A consumer records minimal relevant request-response examples as a contract. The provider runs those expectations against an isolated version and publishes the verification result.

The release decision must connect concrete consumer and provider versions. Over-specific examples couple to irrelevant fields; missing negative cases overlook error semantics and business meaning.

API Contracts describe the full provider boundary. API Versioning covers compatible evolution and parallel contract versions.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
What is the core task of Consumer-Driven Contract Testing?
View the solution with justification
Consumer-driven contract testing lets consumers publish executable expectations that the provider verifies against its current implementation in the build pipeline.
ApplyingTransferred to a new situation
Which assumption is hypothetical in the shop?
View the solution with justification
Order consumes Payment’s internal contract for authorization status and rejection reason. The Order team publishes a contract with success and rejection examples; Payment verifies it in the pipeline for every change.
EvaluateWeighing an alternative
Which three points require evidence before adoption?
View the solution with justification
Consumer expectation, Provider verification, Version matrix.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

Next in Communication & APIs: Synchronous communication.

23 Building blocks

Continue withSynchronous communication