Verifying Pacts
See Verifying Pacts for an introduction into this topic.
Using rake pact:verify
Using the pact:verify
task is the most common way to verify pacts. This is where you configure the default set of pacts that your service provider should honour.
It is made available by requiring 'pact/tasks'
in your Rakefile.
The pacts that will be verified by the pact:verify
task are configured in the pact_helper.rb
file in your provider codebase.
The file must be called pact_helper.rb
, however there is some flexibility in where it can be stored.
The recommended place is spec/service_consumers/pact_helper.rb
.
To ensure that the latest version of the consumer pact is used each time, it is recommended that you either use a Pact Broker or that you publish the pacts of a successful consumer build as artefacts in your CI system.
Note: Pact uses Rack::Test, and assumes that your service provider will be a Rack app. See below for options if your provider is not a Rack app.
With basic auth
To verify a pact from a URL that requires basic auth, add username and password parameters:
With a bearer token
To verify a pact from a URL that requires a bearer token, add the token parameter:
Fetching pacts from a pact broker
To verify pacts with the specific tag(s):
Enabling pending pacts
The "Pending Pacts" feature allows pacts that have been changed by the consumer to be verified by the provider without breaking the provider's build. Read more here. Requires version 1.53.0 or later of the pact gem, and version 2.60.1 or later of the Pact Broker.
Enabling WIP pacts
The "Work In Progress Pacts" feature automatically includes new pacts in the list of pacts to be verified, allowing the consumer to get feedback on a pact without anyone in the provider team having to change the verification configuration. Read more here. Requires version 1.53.0 or later of the pact gem, and version 2.60.1 or later of the Pact Broker.
Publishing verification results to a pact broker
If you are using version 1.11.0 or later of the pact gem and 2.0.0 or later of the Pact Broker, you can automatically publish the results of pact verifications back to the broker by setting the app_version
and publish_verification_results
options in your service provider configuration.
You should only publish verification results from your CI server, not from your local development machine. The recommended way to do this is to detect an environment variable that will only be present on your CI server, like BUILD_NUMBER
or TRAVIS
, or to set an explicit variable like PUBLISH_VERIFICATION_RESULTS
.
See Versioning in the Pact Broker for more information on what the value of the version field should contain. If you're in a hurry, the summary is: use the git sha for the app version, and the git branch for the app version tag.
If your pact URL includes basic auth configurations for the pact broker, these will be used to publish the verification.
Verifying a pact at any URL using rake pact:verify:at
You can verify a pact at any arbitrary local or remote URL using the pact:verify:at
task.
This is useful when you are developing the consumer and provider concurrently, and wish to verify the pact you have just generated in the consumer code base. It will use the same pact_helper file as pact:verify
.
With basic auth, set the environment variables PACT_BROKER_USERNAME
and PACT_BROKER_PASSWORD
, or use the basic auth URL format, http://username:password@pactbroker.yourdomain/...
.
Using a custom pact:verify task
To make a shortcut task for verifying a pact an arbitrary URL that you do not want to verify as part of your normal pact:verify task, (eg. when you are developing the consumer and provider side by side, and want a shorter feedback cycle than can be provided by by your CI box) add the following to your Rakefile. The pact.uri may be a local file system path or a remote URL.
With basic auth, set the environment variables PACT_BROKER_USERNAME
and PACT_BROKER_PASSWORD
, or use the basic auth URL format, http://username:password@pactbroker.yourdomain/...
.
With bearer token auth, set the environment variable PACT_BROKER_TOKEN
.
Verifying one interaction at a time
At some stage, you'll want to be able to run your specs one at a time while you implement each feature. To do this, set the PACT_BROKER_INTERACTION_ID
environment variable (if the pact came from a Pact Broker, and is using a recent version of the gem) or the PACT_DESCRIPTION
and/or PACT_PROVIDER_STATE
environment variables otherwise. At the bottom of the failed pact:verify output you will see the commands to rerun each failed interaction individually. A command to run just one interaction will look like this if it has come from a Pact Broker:
If it has come from a local file, then you can set the provider state and/or description environment variables.
Modifying the request with live data
Some times you may need to modify the request with data that you only know at run time, like authentication data. If you can't stub the authentication in your rack app, then you can use a proxy app as follows.
Be very careful here that you are only changing existing data in the request - if you add something that the consumer did not actually send in the request, then the request may fail in real life because the consumer does not know it needs to be sent.
Configuring RSpec
Pact uses dynamically created RSpec specs to verify pacts. If you want to modify the behaviour of the underlying RSpec execution, you can:
- Configure RSpec in the pact_helper using the normal
RSpec.configure
code. - Set
task.rspec_opts
in your custom rake VerificationTask, the same way you would with a normal RSpec rake task declaration.
For future proofing though, try to use the provider state set_up/tear_down blocks where you can, because we may swap out RSpec for custom verification code in the future.
Pact Helper location
The search paths for the pact_helper are: