Probabably the biggest limitation with Pact's consumer-driven contract tests (for us) has been ensuring exhaustive enum (or object literal) compatibility. That is to say - if the provider response looks like

{
  animalType: "Cat" | "Dog" | "Mouse"
}

then we need it to be a breaking change if the provider might start returning an

animalType

of "Giraffe". As far as I know, there's no real solution for that with consumer-driven contract testing. The consumer contract can say

animalType: regex('Cat|Dog|Mouse', 'Dog'),

That will result in a contract-by-example having "Dog". But when the provider evaluates itself against that contract, the evaluation will succeeed so long as the test doesn't set the

animalType

to "Giraffe" (even though it could in production). We're wondering - does switching to bi-directional contract testing solve this problem? If the provider publishes an OAS schema that says (under version 2.0.1 of the provider)

animalType

can now take on a value of "Giraffe", that version of the provider is incompatible with the consumer? Slack Conversation