Today we will introduce how to set up a provider test, manage state, verify the contract.
Consumer-Driven Contract Testing is driven by the consumer and the provider pulls the interactions down from the Pact Broker and runs them against their local environment. We are going to use pact-verifier to verify our contracts.
A typical scenario where the provider comes in is when the Front-End team is interacting with the provider API. Once the provider has been verified, you will want to communicate the status back to the consumer on whether they can deploy their version of the application containing the new Pact contract or not.
Verifying Pacts Against a Service
In addition to writing Pacts for Python consumers, you can also verify those Pacts against a provider of any language. There are two ways to do this.
CLI
After installing pact-python a pact-verifier application should be available. The simplest example is verifying a server with locally stored Pact files and no provider states:
Which will immediately invoke the Pact verifier, making HTTP requests to the server located at http://localhost:8080 based on the Pacts in ./pacts/consumer-provider.json and reporting the results.
There are several options for configuring how the Pacts are verified:
–provider-base-url
Required. Defines the URL of the server to make requests to when verifying the Pacts.
–pact-url
Required if –pact-urls not specified. The location of a Pact file you want to verify. This can be a URL to a Pact Broker or a local path, to provide multiple files, specify multiple arguments.
–provider-states-setup-url
The URL which should be called to setup a specific provider state before a Pact is verified. This URL will be called with a POST request, and the JSON body {consumer: ‘Consumer name’, state: ‘a thing exists’}.
–custom-provider-header
Header to add to provider state set up and pact verification requests.
-t, –timeout
The duration in seconds we should wait to confirm that the verification process was successful. Defaults to 30.
-r, –publish-verification-results
Publish verification results to the broker.
Python API
You can use the Verifier class. This has all the same parameters as the cli tool but allows you to write native python code and the test framework of your choice.
Provider States
In many cases, your contracts will need very specific data to exist on the provider to pass successfully. If you are fetching a user profile, that user needs to exist, if querying a list of records, one or more records needs to exist. To support decoupling the testing of the consumer and provider, Pact offers the idea of provider states to communicate from the consumer what data should exist on the provider.
When setting up the testing of a provider you will also need to setup the management of these provider states. The Pact verifier does this by making additional HTTP requests to the –provider-states-setup-url you provide. This URL could be on the provider application or a separate one. Some strategies for managing state include:
- Having endpoints in your application that are not active in production that create and delete your datastore state
- A separate application that has access to the same datastore to create and delete, like a separate App Engine module or Docker container pointing to the same datastore
- A standalone application that can start and stop the other server with different datastore states
Conclusion
We have now completed all the tutorials on Contract Testing, each step takes you one step closer to achieving continuous deployment. In achieving this within your organization you will have:
- Improved communication within your microservices.
- Reduced time to release.
- Increased understanding of consumer behaviors and interactions.
Find us if you interested in Contract Testing.
