Difficulty: Intermediate
Estimated Time: 30 minutes

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:

  1. set up a Pact Broker on Kubernetes
  2. write a consumer that defines and publishes Pact contracts
  3. deploy and run a few Spring Boot microservices on Kubernetes
  4. connect microservices to a database and public data source
  5. verify the consumer pacts against a producer
  6. 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.

Lessons Learned

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

References


For a deeper understanding of these topics and more join
Jonathan Johnson
at various conferences, symposiums, workshops, and meetups.

Software Architectures ★ Speaker ★ Workshop Hosting ★ Kubernetes & Java Specialist

Consumer-driven Contracts with Kubernetes

Step 1 of 13

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 && \ kubectl cluster-info

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

Kubernetes Dashboard

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:

token.sh

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

Terminal
Kubernetes Dashboard
Pact Broker
H2
Population
COVID-19
Aggregator