A component that initiates a HTTP request to another component (the service provider). Note that this does not depend on the way the data flows - whether it is a
GET or a
PATCH, the consumer is the initiator of the HTTP request.
A server that responds to an HTTP request from another component (the service consumer). A service provider may have one or more HTTP endpoints, and should be thought of as the "deployable unit" - endpoints that get deployed together should be considered part of the same provider.
Used by tests in the consumer project to mock out the actual service provider, meaning that integration-like tests can be run without requiring the actual service provider to be available.
A request and response pair. A pact consists of a collection of interactions.
A file containing the JSON serialised interactions (requests and responses) that were defined in the consumer tests. This is the Contract. A Pact defines:
- the consumer name
- the provider name
- a collection of interactions
- the pact specification version (see below)
To verify a Pact contract, the requests contained in a Pact file are replayed against the provider code, and the responses returned are checked to ensure they match those expected in the Pact file.
A name describing a “state” (like a fixture) that the provider should be in when a given request is replayed against it - e.g. “when user John Doe exists” or “when user John Doe has a bank account”. These allow the same endpoint to be tested under different scenarios.
A provider state name is specified when writing the consumer specs, then, when the pact verification is set up in the provider the same name will be used to identify the set up code block that should be run before the request is executed.
Each language implementation of Pact needs to implement the rules of this specification, and advertise which version(s) are supported, corresponding closely to which features are available.