Consumer-Driven Contract Testing with Pact - The basics

I'll try to keep this as short as possible. This article is meant to give a quick introduction so you can understand the basics.

What is contract testing?

Contract testing was coined by Martin Fowler and he has a great article on his bliki describing how to it works.

I recommend you read that article first if you don't know what contract testing is or what it's used for, but in short, it's a better way to do most E2E testing, especially in a microservices environment.

What is Pact and Pact CDC testing?

Pact is an open source Contract Testing tool. It helps you implement contract testing and integration in the CI/CD pipeline.

Consumer-Driven Contract Testing (CDC) is one way that Pact implements contract testing.

In principle it has two major steps:

1. First a contract definition at the consumer, through so called "interactions", followed by consumer validation through unit tests, and then contract generation so that the validated expectations of the consumer can now be shared with providers so they can validate if they support those expectations.
2. And secondly, contract validation at the provider, where each provider targeted by a contract validates that it meets the expectations of the consumers that generated the contracts.

How does it work?

1. Consumers

Consumers write unit tests for pieces of code that would interact with an external provider, like usual, asserting that the integration handles errors and data mapping correctly.

Typically these tests would require mocking out the provider through something like Mock Service Worker (MSW).

Instead of using MSW directly, these unit tests will instead declare their expectations through so called interactions and pass them to Pact, which will generate a mock provider set up to behave according to the declared interactions. The mock provider acts just like MSW would.

The unit tests run and if they pass, Pact generates .pact files which contain the consumer expectations and interactions. CI would typically run a script to upload these pact files to PactFlow, which is a contract/pact broker as-a-service.

2. Providers

Providers also write unit tests for their handling of the requests coming from their consumers. In an MVC architecture for example, that would be controller tests that assert that the provider can correctly handle a request.

Instead of writing the requests manually, Pact provides a Verifier class that will download all relevant pacts from PactFlow and replay the interactions declared in them by sending the provider all the requests as they are defined in the interactions, and then comparing the responses the provider gives with the responses from the interactions.

If all expectations are met and the tests pass, the verifier tells PactFlow that the contract has been validated by the provider. With this information you can now safely deploy.

Summary and Benefits

Consumer teams can create and maintain Pact contracts independently of the provider teams. This allows consumers to define their requirements and expectations without being reliant on provider implementation details.

Pact contract tests are typically integrated into the continuous integration (CI) pipelines of both consumers and providers.

Whenever changes are made to either side, the tests are automatically run to ensure that the contracts are still in alignment, facilitating seamless integration and continuous delivery.

For a straightforward and practical code example of CDC testing, click here.