workable-pact-provider-verifier

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
      [--pact-broker-base-url=PACT_BROKER_BASE_URL]                          # Base URL of the Pact Broker from   which to retrieve the pacts.
  -n, [--broker-username=BROKER_USERNAME]                                    # Pact Broker basic auth username
  -p, [--broker-password=BROKER_PASSWORD]                                    # Pact Broker basic auth password
  -k, [--broker-token=BROKER_TOKEN]                                          # Pact Broker bearer token
      [--provider=PROVIDER]
      [--consumer-version-tag=TAG]                                           # Retrieve the latest pacts with   this consumer version tag. Used in conjunction with --provider. May be specified multiple times.
      [--provider-version-tag=TAG]                                           # Tag to apply to the provider   application version. May be specified multiple times.
  -a, [--provider-app-version=PROVIDER_APP_VERSION]                          # Provider application version,   required when publishing verification results
  -r, [--publish-verification-results], [--no-publish-verification-results]  # Publish verification results to   the broker
      [--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.
      [--custom-middleware=FILE]                                             # Ruby file containing a class   implementing Pact::ProviderVerifier::CustomMiddleware. This allows the response to be modified before   replaying. Use with caution!
  -v, [--verbose=VERBOSE]                                                    # Verbose output
  -f, [--format=FORMATTER]                                                   # RSpec formatter. Defaults to   custom Pact formatter. Other options are json and RspecJunitFormatter (which outputs xml).
  -o, [--out=FILE]                                                           # Write output to a file instead   of $stdout.
      [--wait=SECONDS]                                                       # The number of seconds to poll for the provider to become available before running the verification
                                                                           # Default: 0

Examples

See the example for a demonstration with a Sinatra API:

cd examples
bundle install
./test.sh

Simple API

Steps:

1. Create an API and a corresponding Docker image for it
2. Publish Pacts to the Pact broker (or create local ones)
3. 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.

Ignore the states array that you will see if you happen to print out the live provider state set up request body - that was an attempt to make the set up call forwards compatible with the v3 pact specification, which allows multiple provider states. Unfortunately, this forwards compatibilty attempt failed, because the v3 provider states support a map of params, not just a name, so it should have been { "state": { "name": "PROVIDER_STATE, "params": {...} } }. See the next section for the actual v3 support.

Pact specification v3 provider state support

The v3 Pact specification adds support for multiple provider states, and provider state params. If you are verifying a pact with multiple provider states, then set up URL will be invoked once for each state. The params hash from the pact will also be passed through in the JSON document with the key name params.

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