👋 folks I recently discovered that the team at Pact forked the old swagger-mock-validator tool. We have a self-hosted pact broker and we wrote some consumer and provider tests (white box style next to the codebase) in Java as a POC. They work great but my dev team is enquiring if we can just use the refined swagger-mock-validator and run the contracts generated by our exiting consumer test against our OpenAPI spec. The service under test already has an OpenAPI spec and the team was wondering if it is worth to write a Provider test instead of just using the validator tool. It sounds really promising with the caveat that the matchers wont work (let me know if I am wrong). Do you think this approach is better than writing a provider test for an already constructed service like ours? Thanks!

The service under test already has an OpenAPI spec and the team was wondering if it is worth to write a Provider test instead of just using the validator tool

this could imply you aren’t going to test your provider at all, so just for clarity, you absolutely still need to ensure your OAS is implemented by your actual API (you can do that without Pact, of course). But it’s a critical step. A provider contract (in this use case) is the combination of the OAS + test results (evidence) to show it works. The OAS alone is just a document that could be created out of thin air. Have a read of https://docs.pactflow.io/docs/bi-directional-contract-testing#comparison-to-pact and see what you think, it talks about the tradeoffs of the approaches. PactFlow integrates this into the system more deeply if you’re interested in a service that packages it all up neatly for you