Hi there. I try to convince my Team, but the argument is still: We use yaml files and an API generator, so what is the real advantage of Pact? For sure, prevent breaking changes! I know that YAML Files still dont prevent Integration Bugs from happening, but what bugs exactly are meant here?

Yo, An OpenAPI and a client SDK based off it, will tie your consumer and provider in lockstep, and you would have to work with the assumption that every endpoint and every field without an object is used by a consumer, which usually doesn't reflect reality. This lack of visibility into consumers exact use cases, and the data they depend on, means more friction on a provider side when making changes to an api. Do you make everything backwards compatible, what about a breaking change, do you start versioning? Consumer driven contract testing and Pact provides actionable insight on both sides of the fence. All of that is not withstanding that Pact utilised with the Pact Broker allows you to create a matrix of your codebases at point in times (you deploy a point in time instance of your application) and want to know if its compatible with an dependants in an environment at any one time. That can help prevent breaking changes in communication making their way into higher level environments and forcing that conversation around design and intent of the services earlier in the SDLC (which is arguably much cheaper)

I’ve written a few posts on this topic also: • https://pactflow.io/blog/schemas-are-not-contracts/ • https://pactflow.io/blog/should-i-write-contract-tests-for-client-sdks/

Yes, contract testing can still provide value in this scenario. A well-written contract testing approach will: • Track which versions are compatible with each other • Protect against deployments that are broken due to communication issues • Protect against breaking semantic changes (eg Admin vs ADMIN for a field that accepts strings) If your communication code is autogenerated, then you still need a way to track which versions are compatible with each other. You also need a way to track and prevent breaking changes - most schema based approaches do this with manual rigour. Manual rigour is effective, but fallible. All schema approaches are syntactic rather than semantic - for example, gRPC prevents syntactic breaking changes by ensuring that all fields have default values. However, this is a bit like saying “all our endpoints use json, so we can’t send incompatible responses”. Just because the payload can be parsed by the consumer doesn’t mean it has meaning to the consumer. Technically, you never need any testing, as all tests are just risk reduction. Schema-based approaches provide some safety over manual implementations, so depending on your needs, the risks might be acceptable. The questions are whether you want to live with the risk of deploying breaking API changes, and whether you are successfully avoiding breaking API changes with your current approaches.