Skip to content

Contract Testing

Contract testing is a way to verify inter-application messages conform to a specification that is defined within a contract. These messages are typically the HTTP requests from one application (the consumer) and the response from another application (the provider).

The message interactions become defined in a contract, or pact, and are shared between applications through Pact Broker.

Pact is a consumer-driven contract testing tool, meaning the expectations for the message interactions are defined in a contract generated by the consumer contract tests.

Topics

  • Kickoff & Team Alignment
  • What & Why for Contract Testing
  • Intro to Pact Broker
  • Consumer Tests
  • Provider Tests
  • Continuous Delivery: Contract Testing in the Pipeline
  • Impact to Deployments and cross-team collaboration

Outcomes

  • Stronger focus on quality and testing between team members
  • Added layer of testing to gate deployments and ensure application stability
  • Increased collaboration between teams

Contract Testing Pilot Agenda

Day 1 and 2

Consumer tests

For folks who are leveraging an API and need to define a contract of expected interactions and request/responses. Pact Broker is a "Consumer Driven" contract testing approach. This means that the consumer defines the expectations for the API, and the provider responds by validating the contract.

Publishing the contract

Interacting with Pact Broker. understanding the role of Pact Broker as a intermediary service for sharing contracts between consumers and providers. Understand the Contract matrix. How to authenticate to Pact Broker. The publishing implementation can be app specific and depend on the language the consumer is written in.

Provider tests

This is a potentially separate team that is acting as the provider and they need their own set of tests for validating the contract. This will involve coordination between teams.

Day 3 and 4

CI Workflow

Implement contract testing workflow in CircleCI. This is on the provider side

  1. Provider - Add labeling to Kubernetes deployment. Intended to trace the running version in each environment back to something in Git

  2. Provider - Add logic to Helm deployment to include Git tag/commit to Helm values

  3. Provider - Add Pact Workflow to provider CircleCI config. Triggered by Pact Broker. This will have parallel jobs for checking out the different versions of the provider in each environment, and running validation against them. Whenever a new version of a contract gets published, this workflow will tell us which versions of the provider the contract is valid with.

  4. Provider - Add pipeline parameters to provider CircleCI config in order to filter which workflow to execute. Also add filters to workflows based on pipeline parameters

  5. Provider/Consumer - Add steps for installing pact-broker CLI tool in pipeline (talk to PE about getting this baked into one of the CircleCI agents)

  6. Consumer - publish initial contract from consumer side.

  7. Consumer - Generate CircleCI token. This will be used by the webhook for Pact Broker

  8. Consumer - Setup webhook in Pact Broker for events whenever a contract changes

  9. Consumer - Add contract testing job to consumer's CircleCI config - dev-release

  10. Consumer - Add can-i-deploy jobs to consumer's CircleCI config - dev-release, qa-release, prod-release