Today we will introduce how to set up a Consumer Pact Test, define the interaction, generate the contract for the API, and run the test in Python.
Consumer-Driven Contract Testing is driven by the consumer, thus we are starting with the Consumer Pact Test.
Pact.io supports multiple programming languages (incl. .Net, Ruby, Python, PHP), for this tutorial we will use Python as programming language.
A typical scenario when you will be implementing consumer-driven contract testing is where the consumer tests are written by the UI team and they are interacting with the back-end API team as the provider.
Write A Consumer Pact Test
Installation
If we have a method that communicates with one of our external services, which we’ll call provider, and our product – Consumer is hitting an endpoint on Provider at /users/<user> to get information about a particular user.
If the code to fetch a user looked like this:
Then Consumer’s contract test might look something like this:
This does a few important things:
- Defines the Consumer and Provider objects that describe our product and our service under test
- Uses given to define the setup criteria for the Provider
- Defines what the request that is expected to be made by the consumer will contain
- Defines how the server is expected to respond
Using the Pact object as a context manager, we call our method under test which will then communicate with the Pact mock service. The mock service will respond with the items we defined, allowing us to assert that the method processed the response and returned the expected value. If you want more control over when the mock service is configured and the interactions verified, use the setup and verify methods, respectively:
When defining the expected HTTP request that your code is expected to make you can specify the method, path, body, headers, and query. You can define exact values for your expected request or you can use the matchers defined later to assist in handling values that are variable.
The mock service offers you several important features when building your contracts:
- It provides a real HTTP server that your code can contact during the test and provides the responses you defined.
- You provide it with the expectations for the request your code will make and it will assert the contents of the actual requests made based on your expectations.
- If a request is made that does not match one you defined or if a request from your code is missing it will return an error with details.
- Finally, it will record your contracts as a JSON file that you can store in your repository.
Expecting Variable Content
The above test works great if that user information is always static, but what happens if the user has a last updated field that is set to the current time every time the object is modified? To handle variable data and make your tests more robust, there are 3 helpful matchers:
Term(matcher, generate)
Asserts the value should match the given regular expression. You could use this to expect a timestamp with a particular format in the request or response where you know you need a particular format, but are unconcerned about the exact date:
Like(matcher)
Asserts the element’s type matches the matcher. For example:
EachLike(matcher, minimum=1)
Asserts the value is an array type that consists of elements like the one passed in. It can be used to assert simple arrays:
Next steps
In this tutorial, we learned the scenarios we would use to perform contract Pact tests and saw how to test different JSON data types.
Follow us you will know more details about verifying Pact Contract .
