Hi I have a provider enum that has two values

public enum defaultSettlementMethod
  {
    Method1= 1,
    Method2 = 2,
  }

In the OAS spec, it shows as "Allowed Values 1 2" (see screenshot) I would like to be able to check in the consumer that it is these values only, rather than have an integration test for this. Is that possible? I know it probably goes against the philosophy of Pact to do this. However in the past we have found that providers may add new values to the enums, and the consumers weren't expecting the change. Adding any kind of test in the provider may still result in the outcome, because this still relies on the provider team communicating the change effectively. Hope that makes sense?

It’s not really something Pact can guard against, unfortunately. Unless you have a way to reliably get the provider to produce all possibly values for that property, Pact won’t be able to say “Ah! That’s not something the consumer allows”. A simpler approach would be, perhaps, we do OAS breaking change detection. E.g. using something like this: https://github.com/bump-sh/cli?tab=readme-ov-file#the-diff-command

thanks 🙂

Are you doing regular Pact or Bi-Directional contract testing?

Bi-Directional. I was looking at the text on the providers open api spec which was imported into the PactFlow broker.

hah. I've asked about this exact same scenario before. I think some kind of comparison based on OpenAPI schema compatibility checking is the way forward. For example, using

openapitools/openapi-diff

- with

--fail-on-incompatible

Interestingly, it would probably be easier to add this kind of functionality to bi-directional contracting in Pact (c.f. consumer-driven contract tests). However you then miss out on the benefits that CDDT has with contract-by-example (I guess that's the reason the docs kind of frame bi-directional contract testing as the "gateway drug")

yeah, that’s right Eddie.