Prove me wrong: Pact (or any form of consumer-driven contract testing) provides little to no value for testing GraphQL APIs. According to https://docs.pact.io/faq/convinceme, “OpenAPI can be used as a contract testing framework in a similar way to Pact”. I would make the argument that the same applies for GraphQL. In both cases, the APIs have a schema with strongly typed definition of field names, types, etc. Testing guidelines on https://docs.pact.io/consumer recommend loose matching (field names and data types only). The example on https://pactflow.io/blog/contract-testing-a-graphql-api/ follows this approach. Assuming I have a way to ensure that there are no breaking changes to the provider’s schema (e.g. by static analysis), what value at all is this contract test providing? Again, please prove me wrong. My organization has all the problems that contract testing purports to solve. I want to make a case for adopting it. But so far I am disappointingly unable to. If I were to follow recommended practices, it would require a LOT of development overhead to implement consumer driven contract tests that provide little to no value given the existence of a strongly typed API with prevention of breaking changes already in place. The only case I can see right now for consumer driven contract tests providing value is if we can use them in place of functional / integration tests for our front end layer. Right now these are heavily reliant on VCR cassettes but are not providing value because the cassettes are brittle and not frequently re-recorded. If we could use contracts in place as the mocking layer, that would ensure that the mocking layer of the consumer integration tests is in sync with the actual APIs. However, that approach is strongly discouraged in https://docs.pact.io/consumer, especially in the video on that page; to quote presenter: “the teams that have done it have really regretted it”.

@Matt Yao might have something to add, do I recall you testing a graphql service recently-ish?

Prove me wrong: Pact (or any form of consumer-driven contract testing) provides little to no value for testing GraphQL APIs.

Why?

We used GraphQL and graphql-codegen to generate the ts-code via the remote schema (we targeted staging API). We've hooked it with husky and found it saved us time to generate code we need in our desired format before we push the changes. Well that is just the GraphQL part, it doesn't provide enough confidence running things on the CI environment as the integrations can still break in any environment when there's a breaking change on the provider side, which are not reflected immediately when we generated the code via the deployed version on staging (which is old). And it happened a few times when the app grows, it got worse. Pactflow came to help with the additional step to check the above before any deployment happens on every environment - what @Timothy Jones said, yes you can deploy on Friday with the beer.

The schema vs contract articles are exactly the explanations I was looking for, thank you!! I was not trying to make a case against Pact, I was trying to understand whether & why it provides value in my case. Sorry if tone did not properly convey that.

Sweet, glad it helped! I did a presentation on a related topic last year albeit in the end I didn't call out graphql