Implementing the provider changes
The next step is to implement the changes that have been requested in the pact.
Open up the terminal for your provider project.
Run
make test
to make sure everything is passing before you start.- Your test run should exit successfully, but show the failing verification from our consumers feature branch. If we didn't have
enablePending
set, this would exit with a failure.
- 👉 This will run our unit tests and our Pact test which "fetch pacts for these consumer version selectors" mode. This is executed as part of the following GitHub workflow
.github/workflows/build.yml
- Your test run should exit successfully, but show the failing verification from our consumers feature branch. If we didn't have
Get the URL of the new pact:
- Go to your PactFlow account, find the new pact on the consumer branch
feat/new-field
and click "VIEW PACT". - In the top right, click the 3 dots and select
Copy pact URL for pactflow-example-consumer version xyz
.
- Go to your PactFlow account, find the new pact on the consumer branch
Run
PACT_URL=<PACT URL HERE> make ci_webhook
. This test should correctly fail with the errorCould not find key "color"
in the output.- 👉 We run a new command here
make ci_webhook
. This allows us to "verify a custom pact", it works because of the code insrc/product/product.consumerChange.pact.test.js
- Rather than our
product.providerChange.pact.test.js
test which "fetch pacts for these consumer version selectors" mode, by runningmake test
who workflow in GitHub is in this file.github/workflows/build.yml
- When running
make ci_webhook
, The$PACT_URL
is passed in when the build is triggered by a "contract requiring verification published" webhook, and allows us to verify just the changed pact against the providers main branch and any deployed (or released) versions. The workflow in GitHub is in this file.github/workflows/contract_requiring_verification_published.yml
- We share the base Pact setup in
src/product/pact.setup.js
for both types of Pact verification, so both can re-useProvider States
/Request filters
and core setup common to both tasks.
- 👉 We run a new command here
Make the test pass by adding a
color
field toproduct/product.js
, and adding the new color argument to the Product initialization lines inproduct/product.repository.js
and the provider states inproduct/pact.setup.js
.constructor(id, type, name, version, color) {
this.id = id;
this.type = type;
this.name = name;
this.version = version;
this.color = color;
}constructor() {
this.products = new Map([
["09", new Product("09", "CREDIT_CARD", "Gem Visa", "v1", "green")],
["10", new Product("10", "CREDIT_CARD", "28 Degrees", "v1", "blue")],
["11", new Product("11", "PERSONAL_LOAN", "MyFlexiPay", "v2", "yellow")],
]);
}const stateHandlers = {
"products exists": () => {
controller.repository.products = new Map([
["10", new Product("10", "CREDIT_CARD", "28 Degrees", "v1","blue")],
]);
},
"products exist": () => {
controller.repository.products = new Map([
["10", new Product("10", "CREDIT_CARD", "28 Degrees", "v1","blue")],
]);
},
"a product with ID 10 exists": () => {
controller.repository.products = new Map([
["10", new Product("10", "CREDIT_CARD", "28 Degrees", "v1","blue")],
]);
},
"a product with ID 11 does not exist": () => {
controller.repository.products = new Map();
},
};Run
PACT_URL=<PACT URL HERE> make ci_webhook
and you should have a passing test suite. ✅We won't commit our changes until the next step.
Expected state by the end of this step​
- A passing provider build in Github Actions.
- Local changes on your provider codebase that implements the features required by the
feat/new-field
pact on itsmaster
branch. - A
feat/new-field
pact with a failed verification result
Conclusion​
The master
provider is now compatible with the feat/new-field
pact, based on your local changes. However, there is still a failing verification result published for the feat/new-field
pact, triggered by a webhook (contract requiring verification published) when the new pact was published.
We verified the Pact would pass against our providers main branch master
by passing in the Pact URL directly, however because it was only verified on a development machine, and we don't typically publish verification results from dev machines.
The next step is getting a result back to PactFlow so that the consumer knows they are safe to merge.