Objectives of this guide
This guide will:
- Explain you the basics of Pact
- Highlight the value over traditional end-to-end integrated tests
- Provide a hands-on Go workshop which explains all of the key-concepts in 1 hour
What is Pact?
Pact is a tool that makes it fast, easy and reliable to test your APIs and microservices during development. It implements a style of testing referred to as consumer-driven contract testing. It's ideally suited to environments where there are a number of teams building out a large distributed system. You can read more about that here, but as a brief introduction:
Contract testing is a technique for testing an integration point by checking each application in isolation to ensure the messages it sends or receives conform to a shared understanding that is documented in a "contract".
For applications that communicate via HTTP, these "messages" would be the HTTP request and response, and for an application that used queues, this would be the message that goes on the queue
This means that you can:
- Deploy services independently of one another, a key tenet of microservices delivery
- Prevent breaking changes from being released
- Avoid expensive and brittle end-to-end tests
It helps you to move both faster and safer. You can read more on the benefits of contract testing here.
How Pact Works
We've created a page dedicated to explaining this concept, so rather than duplicate it - we'll wait for you here :)
Once you have the concepts down pat, the process looks like this:
- Create a consumer Pact test
- Publish the pact test to a broker (using a service like Pactflow)
- Verify the consumer test with your API Provider (Provider Pact test)
can-i-deployto your build pipeline
- Ship it 🚀
It really is that easy. Let's get our hands dirty, shall we?
We've hand-crafted a workshop designed to explain all of the key concepts in Pact, in order, to take you from a n00b to a "I can POC this" in about one hour. Here is an overview of the 11 steps in the workshop:
|Step||Title||Concept Covered||Learning objectives|
|step 1||Create our consumer before the Provider API even exists||Consumer-driven design||
|step 2||Write a unit test for our consumer||-||
|step 3||Write a Pact test for our consumer||Consumer side pact test||
|step 4||Verify the consumer pact with the Provider API||Provider side pact test||
|step 5||Fix the consumer's bad assumptions about the Provider||Humans talking to humans (collaboration)||
|step 6||Write a pact test for
||Testing API invariants||
|step 7||Update API to handle
|step 8||Write a pact test for the
||Testing authenticated APIs||
|step 9||Update API to handle
|step 10||Fix the provider to support the
|step 11||Implement a broker workflow for integration with CI/CD||Automation||
Head over to https://github.com/pact-foundation/pact-workshop-go to get started.
Now that you have a good understanding of Pact, why not sit down with your team and scratch out the shape of a POC?
Created by the team that brought you Pact, our vision is to transform the way teams test and release distributed systems. As the leading contract-testing collaboration platform we are making it easier than ever to test and deploy microservices, serverless functions and APIs.
Like to get in touch, drop as a email - we'd love to say hi!