Hey everybody 👋 Get more of your team involved and maintain traction to ensure a successful rollout of your contract testing initiative using our tooling integration, made possible with Bi-Directional Contract Testing. This week we hosted two Pactflow customer webinars providing demos using Cypress for consumer contracts, OpenAPI documentation for provider contracts and Postman. The recordings are now available on YouTube if you’d like to view / share with your team: Using OpenAPI Documentation in Contract Testing with Pactflow Using Cypress and Postman for Contract Testing with Pactflow Plus some more details. Check the thread 🧵 👇

Hi @Yousaf Nabi (pactflow.io) thanks a lot for that demo. In the Cypress & Postman video you speak about unused fields in the fixtures that would unnecessarily prevent the provider from making changes. Would it make sense to remove these fields from the fixture even though that wouldn't represent the true (whole) response? Or is this a compromise of using this method? Timestamp:

Hey @Cameron Allan , sorry I missed this in my notifications. No worries, my pleasure. Hope to more in the future and maybe some specific videos where I go over the details of each of our tool integrations. Re: fixtures on the consumer side. I suppose it depends on where you are in your journey. Say you just a testing team, maintain a set of mocks, which your consumers use, but represent your providers. You may have a single mock service that provides the full set of provider responses, so it isn’t coupled to a consumers specific needs. Using the full fat mock for validation against the provider would ensure that your mocks don’t stay out of sync. If your consumer adds a new field, they would want some tests against the fixtures, in which it would fail, giving them feedback pre deployment. If the case mentioned where a consumer fixture has a field unused by the consumer, the provider would remove it and publish their OAS spec. It would fail against the consumer fixture’s generated Pact file. You would then want a conversation to update your fixtures, and re-run your consumer side tests, make sure they are good, generate a Pact, verify and you are good to deploy. If you can generate the Pact files from the consumer side code directly, I am always in favour of that, and fortunately you can use the existing Pact framework on your consumer side, along our new Bi-Directional cross-contract validation.

Awesome thank you for clarifying 🙂

No worries man, if you have any specifics about your particular domain be sure to ask on here as there is loads in the community who want to help 🙂