[Introduction to contract testing - Part 2] Contract testing and how Pact works

Summary

The video explains consumer-driven contract testing and how Pact checks compatibility between systems without relying on full end-to-end integration tests.

API specifications and consumer-driven contracts

OpenAPI/Swagger and RAML help teams communicate an API’s design, but a specification alone does not ensure that consumers have kept up with changes. A provider may change its API while a consumer still relies on an older version, causing an integration to break.

Consumer-driven contracts reverse the direction: consumers specify what they need, and providers verify that they continue to support those requirements.

What contract testing does

Contract testing checks requirements at each integration point. Instead of running the entire system together, teams capture each side’s expectations in a contract and verify them independently.

This approach can offer several benefits:

• Tests are simpler and do not require every dependent service to be running.
• Teams can often test locally without dedicated integration-test environments.
• Feedback is fast and reliable, and test suites can scale without running the whole system.
• Components can be released independently.
• Verified contracts help teams identify compatible components when coordinating releases.

What Pact is

Pact is an open-source, consumer-led contract-testing tool. It combines tests on both sides of an integration and uses contracts to check that those tests remain aligned. The goal is to reduce reliance on end-to-end testing and complex test environments.

Pact is not limited to microservices. It can be used wherever systems communicate over protocols such as HTTP or through messages. Examples include web and mobile applications, REST services, embedded devices, and message queues.

Pact workflow for HTTP

The video uses a website and a backend service as an example:

• Consumer: The website requests data.
• Provider: The backend supplies it.
• Their HTTP requests and expected responses form the contract.

The workflow is as follows:

1. Consumer test: Pact provides a mock provider. The consumer sends requests to it, and the test checks that the consumer makes the expected calls and can handle the responses. If the test fails, no contract is produced.
2. Share the contract: The contract is published to a Pact Broker, where it can be versioned and shared. PactFlow is mentioned as a commercial broker.
3. Provider verification: Pact retrieves consumer contracts from the broker and replays their requests against the provider. It checks that the responses match the expected details, including headers, status codes, and bodies.

The consumer and provider are tested independently rather than run together.

Pact workflow for asynchronous messages

For message-based systems, the example is a product catalog consuming messages from a Kafka topic published by an order-management system:

• Consumer: The system that handles the message.
• Provider (producer): The system that creates the message.
• The contract covers the message and relevant metadata, such as the topic and content type.

The workflow is as follows:

1. Consumer test: Pact acts as the message source, supplies a sample message, and invokes the consumer’s handler to check that it processes the message.
2. Share the contract: The contract is published to the Pact Broker for versioning and collaboration.
3. Provider verification: Pact invokes the provider’s message-producing function and checks that the generated message and metadata match the contract.

Speaker and source

A single presenter from PactFlow explains the concepts and workflows. No individual speaker is named in the subtitles.