Pact Provider Verification
This setup simplifies Pact Provider verification process in any language, wrapping the Ruby implementation into a cross-platform, binary-like CLI tool.
Features:
- Verify Pacts against Pacts published to an http endpoint, such as a Pact Broker
- Verify local
*.json
Pacts on the file system - Works with Pact provider states should you need them
- Publishes the verification results back to the pact broker if the pact was retrieved from a broker.
Installation
Docker
Take a look at https://github.com/DiUS/pact-provider-verifier-docker.
Native Installation
Download the appropriate release
for your OS and put somewhere on your PATH
.
With Ruby on Mac OSX and Linux
gem install pact-provider-verifier
pact-provider-verifier <args>
Run pact-provider-verifier help
for command line options.
Usage
Usage:
pact-provider-verifier PACT_URL ... -h, --provider-base-url=PROVIDER_BASE_URL
Options:
-h, --provider-base-url=PROVIDER_BASE_URL # Provider host URL
-c, [--provider-states-setup-url=PROVIDER_STATES_SETUP_URL] # Base URL to setup the provider states at
-a, [--provider-app-version=PROVIDER_APP_VERSION] # Provider application version, required when publishing verification results
-r, [--publish-verification-results=PUBLISH_VERIFICATION_RESULTS] # Publish verification results to the broker
-n, [--broker-username=BROKER_USERNAME] # Pact Broker basic auth username
-p, [--broker-password=BROKER_PASSWORD] # Pact Broker basic auth password
[--custom-provider-header=CUSTOM_PROVIDER_HEADER] # Header to add to provider state set up and pact verification requests. eg 'Authorization: Basic cGFjdDpwYWN0'. May be specified multiple times.
-v, [--verbose=VERBOSE] # Verbose output
-f, [--format=FORMATTER] # RSpec formatter. Defaults to custom Pact formatter. json and RspecJunitFormatter may also be used.
-u, [--pact-urls=PACT_URLS] # DEPRECATED. Please provide as space separated arguments.
Verify pact(s) against a provider. Supports local and networked (http-based) files.
Examples
See the example for a demonstration with a Sinatra API:
cd examples
bundle install
./test.sh
Simple API
Steps:
- Create an API and a corresponding Docker image for it
- Publish Pacts to the Pact broker (or create local ones)
- Run the CLI tool for your OS, passing the appropriate arguments:
- a space delimited list of local Pact file URLs or Pact Broker URLs.
--provider-base-url
- the base url of the provider (i.e. your API)
eg.
pact-provider-verifier foo-bar.json --provider-base-url http://localhost:9292
Setting a custom Authentication header
If you need to set a valid Authentication header for your replayed requests and provider state setup calls, specify --custom-provider-header "Authentication: Type VALUE"
in the command line options.
Modification of the request headers is sometimes necessary, but be aware that any modification of the request before it is replayed lessens your confidence that the consumer and provider will work correctly in real life, so do it with caution.
API with Provider States
Read the Provider States section on docs.pact.io for an introduction to provider states.
To allow the correct data to be set up before each interaction is replayed, you will need to create a dev/test only HTTP endpoint that accepts a JSON document that looks like:
{
"consumer": "CONSUMER_NAME",
"state": "PROVIDER_STATE"
}
The endpoint should set up the given provider state for the given consumer synchronously, and return an error if the provider state is not recognised. Namespacing your provider states within each consumer will avoid clashes if more than one consumer defines the same provider state with different data.
The following flag is required when running the CLI:
--provider-states-setup-url
- the full url of the endpoint which sets the active consumer and provider state.
Rather than tearing down the specific test data created after each interaction, you should clear all the existing data at the start of each set up call. This is a more reliable method of ensuring that your test data does not leak from one test to another.
Note that the HTTP endpoint does not have to actually be within your application - it just has to have access to the same data store. So if you cannot add "test only" endpoints during your verification, consider making a separate app which shares credentials to your app's datastore. It is highly recommended that you run your verifications against a locally running provider, rather than a deployed one, as this will make it much easier to stub any downstream calls, debug issues, and it will make your tests run as fast as possible.
Using the Pact Broker with Basic authentication
The following flags are required to use basic authentication with a Pact Broker:
--broker-user
- the Username for Pact Broker basic authentication.--broker-password
- the Password for Pact Broker basic authentication.
NOTE: the http://user:password@host
format for basic HTTP auth is not supported.
Contributing
See CONTRIBUTING.md