It is important you use a mock and not a stub. The crucial difference is that a mock validates behaviour, a stub does not. We need to ensure that your consumer code actually calls the mock, otherwise we will serialise a contract with invalid expectations.
If you're not using Pact, you need to pick a tool that you are able to extract the mocking information from or use a pre-existing adapter, in order to convert it to a pact file.
Some tools have options to serialise their mocks to a file, and others will require you to introspect via their APIs. You should take this into consideration in advance.
Once you have chosen your tool, you must implement your consumer side tests. It is important here that you exercise all of the API behaviour your system expects to ensure you have the coverage you need.
One notably deviation from Pact advice is that you need not concern yourself with finding the minimual set of tests for a contract, and are free to use mocks for any fuctional testing. In fact, this is encouraged.
(Reference to standard contract testing advice: https://docs.pact.io/consumer/contract_tests_not_functional_tests/)
NOTE: If you chose Pact in Step 1, you can skip to Step 3.
Read the documentation on how to generate a pact contract from your mocks.
We will be building adapters for common mocking tools as we expand this feature. See current community contributed adapters below.
Uploading a pact file is the same as the standard Pact process.
We recommend using the
pact-broker publish command from CLI Tools for this step. Our examples use the Docker version of this to simplify administration.
can-i-deploy gives you immediate feedback if you are safe to release a version of an application to a specified environment (such as
We recommend using the
pact-broker can-i-deploy command from CLI Tools for this step. Our examples use the Docker version of this to simplify administration.
The output from the command will provide a link to the verification result in Pactflow. Interpreting these results is contract specific.
can-i-deploy returns a successful response, you can deploy your application. Once your application is deployed, you can notify Pactflow of the release - follow the golden rule of tagging here.
Golden rule of tagging:
Tag with the branch name when you publish pacts or verification results, and tag with the environment name when you deploy.
A simplified view of a CI/CD pipeline for Pact looks like this:
The following are adapters for common tools that provide a mocking capability that you can use to immediately generate pact files from:
- Mock Service Worker (MSW): https://github.com/YOU54F/msw-pact
- Wiremock: https://bitbucket.org/atlassian/wiremock-pact-generator
If you'd like to create or request one, please contact us.