Transcripted Summary
Many of the best practices for using Pact are also the best practices of versioning. Therefore, many teams find that the introduction of Pact requires a move to more principled versioning practices.
The following guidelines are grouped by applicability to consumer and provider perspectives.
Consumer: Don’t Use Random Data
You should never use random data. Use static data instead. If contracts contain random data, a unique Pact contract may be created when the contract has not actually changed.
// Bad practice
const EXPECTED_BODY = {
name: fake.name,
surname: fake.surname,
createdDate: Date.now(),
country: fake.country()
}
// Good practice
const EXPECTED_BODY = {
name: "Foor",
surname: "bar",
createdDate: "2020-04-21",
country: "UK"
}
Consumer: Isolate Tests
Test isolation is generally a good practice to follow for any kind of test.
Consumer: Avoid Tests with UI Integration
UI Integration is unnecessary. Recall that the tests you are targeting reside in the following layer:
Consumer: Keep Contracts Up to Date in your Pact Broker
Up-to-date contracts ensure that testing is performed using the latest version.
Consumer: Test Coverage with Pact
Check test coverage with Pact by verifying that all calls to the provider go to classes that have been tested with Pact.
Consumer: Use Models Carefully
Ensure that the models you are using for tests can actually be created from the responses you expect.
Consumer: Be Careful with Garbage In/Garbage Out
To avoid a garbage in, garbage out situation, expect the response body to contain the newly updated values of the resource. Avoid the scenario of having an optional misnamed field being ignored and then receiving a nominal status code of 200, effectively failing to alert you to the fact that your field is not even expected.
Consumer: Use can-i-deploy
Use the can-i-deploy tool which is part of the Pact broker common line interface and is available via Docker or as an executable installable through a script. A typical usage example follows:
$ pact-broker can-i-deploy --participant Cat --version 21 --participant Dog --version 32
This tool ensures that you are deploying a version that is still compatible with the other services. If the command exit code is zero, it indicates that it is safe to deploy. The can-i-deploy tool pings the broker to check if a consumer contract was verified by the provider. If it was not verified, this indicates that you should avoid deploying or tagging a contract as production-ready because it has yet to be implemented by a provider.
Provider: Don’t Manually Copy Contracts
Contracts should not be manually copied. Ensure that the latest Pact is verified and mitigate your risk.
Provider: Add Pact to your CI
Integrate Pact into your Continuous Integration workflow to increase confidence in a successful deployment into production.
Provider: Don’t Stub Unless Necessary
Don't stub if you don't need to. Only stub code that is executed after the contents of the request body has been extracted and validated. Otherwise, you could potentially send any old garbage in a post or Pact body and no test would fail.
Provider: Stub Calls for Downstream Systems
Stub calls for downstream third-party systems or consider making a separate Pact with downstream systems using shared fixtures.
Provider: Publish Verification to Pact Broker
When a Pact is verified against a provider, the outcome of that verification must be made available to the consumer and provider teams. A determination can then be made as to whether or not the code in either project can be safely deployed. The Pact verification tool can automatically publish verification results back to the broker and they will be displayed on the index page.
Provider: Provider and Consumer Languages
Pact supports different languages, giving you the flexibility to write the provider and the consumer in different languages.
Provider: Collaborative Effort
While Pact is marketed as consumer-driven contract creation, this should not be interpreted as giving the consumer team free reign to write whatever Pacts they wish, leaving the provider team to deal with the output. The Pact should be the starting point of a collaborative effort.
