Standalone Pact Verifier
This project provides a command line interface to verify pact files against a running provider. It is a single executable binary. It implements the V3 Pact specification.
The Pact Verifier works by taking all the interactions (requests and responses) from a number of pact files. For each interaction, it will make the request defined in the pact to a running service provider and check the response received back against the one defined in the pact file. All mismatches will then be reported.
Command line interface
The pact verifier is bundled as a single binary executable pact_verifier_cli. Running this with out any options displays the standard help.
Options
Log Level
You can control the log level with the -l, --loglevel <loglevel> option. It defaults to warn, and the options that you can specify are: error, warn, info, debug, trace, none.
Pact File Sources
You can specify the pacts to verify with the following options. They can be repeated to set multiple sources.
| Option | Type | Description |
|---|---|---|
-f, --file <file> | File | Loads a pact from the given file |
-u, --url <url> | URL | Loads a pact from a URL resource |
-d, --dir <dir> | Directory | Loads all the pacts from the given directory |
-b, --broker-url <broker-url> | Pact Broker | Loads all the pacts for the provider from the pact broker. Requires the -n, --provider-name <provider-name> option |
Provider Options
The running provider can be specified with the following options:
| Option | Description |
|---|---|
-h, --hostname <hostname> | The provider hostname, defaults to localhost |
-p, --port <port> | The provider port (defaults to protocol default 80/443) |
-n, --provider-name <provider-name> | The name of the provider. Required if you are loading pacts from a pact broker |
--base-path <base-path> | If the provider is mounted on a sub-path, you can use this option to set the base path to add to all requests |
Filtering the interactions
The interactions that are verified can be filtered by the following options:
-c, --filter-consumer <filter-consumer>
This will only verify the interactions of matching consumers. You can specify multiple consumers by either separating the names with a comma, or repeating the option.
--filter-description <filter-description>
This option will filter the interactions that are verified that match by description. You can use a regular expression to match.
--filter-state <filter-state>
This option will filter the interactions that are verified that match by provider state. You can use a regular
expression to match. Can't be used with the --filter-no-state option.
--filter-no-state
This option will filter the interactions that are verified that don't have a defined provider state. Can't be used
with the --filter-state option.
State change requests
Provider states are a mechanism to define the state that the provider needs to be in to be able to verify a particular request. This is achieved by setting a state change URL that will receive a POST request with the provider state before the actual request is made.
NOTE: For verifying messages fetched via HTTP, the provider state is also passed in the request to fetch the message, so the state change URL is not required.
-s, --state-change-url <state-change-url>
This sets the URL that the POST requests will be made to before each actual request.
--state-change-as-query
By default, the state for the state change request will be sent as a JSON document in the body of the request. This option forces it to be sent as a query parameter instead.
--state-change-teardown
This option will cause the verifier to also make a tear down request after the main request is made. It will receive a second field in the body or a query parameter named action with the value teardown.
Example run
This will verify all the pacts for the happy_provider found in the pact broker (running on localhost) against the provider running on localhost port 5050. Only the pacts for the consumers Consumer and Consumer2 will be verified.
Verifying message pacts
Message pacts can be verified, the messages just need to be fetched from an HTTP endpoint. The veryfier will send a POST request to the configured provider and expect the message payload in the response. The POST request will include the description and any provider states configured in the Pact file for the message, formatted as JSON.
Example POST request: