Consumer-drive contracts (CDC) was first promoted as a testing technique in 2006 by Ian Robinson. CDC has been slow to adapt over the years, but remains a vital testing technique. Recently our community has adopted a keener interest in CDC as it's a helpful method for testing microservices.
CDC is a concept and testing approach that embraces the perspective of multiple consumers that communicate with providers. Typically, testing tends to define API contracts from the providers perspective. Through a registry of contracts, multiple consumers now have a voice to provide producers their expectations on how data should be exchanged between the consumers and producers.
Over the years the Pact Foundation has established itself as the primary framework that implements this testing approach.
This scenario leverages on Kubernetes as it's ideal for running microservices and containers.
You will explore a sample application composed of several microservices. The application aggregates population and COVID-19 datasources and presents data at an API gateway. We will use Pact to verify the API.
You will learn how to:
- set up a Pact Broker on Kubernetes
- write a consumer that defines and publishes Pact contracts
- deploy and run a few Spring Boot microservices on Kubernetes
- connect microservices to a database and public data source
- verify the consumer pacts against a producer
- find API defects and fix them
Hopefully, you can now start to see how changing the perspective of test by embracing the consumer perspectives can be a powerful testing technique, especially for Microservices.
With an established library of contacts, a producer writer can have much more confidence when making adjustments to the API that others consume. With any change they can run
pactVerify, to help understand the impact of changes to their consumers.
Consumers can work with customer requirements and evolving APIs by mocking up new communication scenarios. Those new contacts can be published and verified against their providers. The Pact contracts provide opportunities for conversations and understanding the impacts of change while maintaining a clean separation between the producers and consumers.
With these steps you have learned how to:
- ✔ set up a Pact Broker on Kubernetes
- ✔ write a consumer that defines and publishes Pact contracts
- ✔ deploy and run a few Spring Boot microservices on Kubernetes
- ✔ connect microservices to a database and public data source
- ✔ verify the consumer pacts against a producer
- ✔ find API defects and fix them
- Consumer-Driven Contracts: A Service Evolution Pattern, Ian Robinson, 2006
- Thoughtworks Tech Radar on Pact
- Pact Foundation
- Pact Broker
- Marie Drake, Contract Testing with Pact.js and Jest
- Spring boot with Docker
- Spring Boot in a Container
- Spring Boot initializr
- Multi-stage Dockerfile
- Alpine virtues: small, simple and secure
Consumer-driven Contracts with Kubernetes
Your Kubernetes Cluster
For this scenario, Katacoda has just started a fresh Kubernetes cluster for you. Verify that it's ready for your use:
kubectl version --short && \
kubectl get nodes && \
kubectl get componentstatus && \
It should list a 2-node cluster and the control plane components should be reporting Healthy. If it's not healthy, try again in a few moments. If it's still not functioning refresh the browser tab to start a fresh scenario instance before proceeding.
The Helm package manager used for installing applications on Kubernetes is also available:
helm version --short
You can administer your cluster with the
kubectl CLI tool or use the visual Kubernetes dashboard. The Dashboard can be accessed from the tab labeled Kubernetes Dashboard above the command line. When the Dashboard first appears, it will prompt for an access token. At any time you can run this script to access the Dashboard token:
This script will display the token in the terminal. Copy the green text using your browser's copy feature then paste the token into the prompt when the Dashboard is accessed. If the Dashboard is still starting up, then Katacoda will report the access error. Once the dashboard Pod reports the status Running it can be accessed:
kubectl get pods -n kube-system -l app.kubernetes.io/name=kubernetes-dashboard