I have a follow-up question on

fromProviderState

design. Where do I ideally draw the line when to use it for argument details that the consumer simply does not care about. Lets say the pact is testing a

hello world

response and the API also requires a somewhat unrelated header that the consumer is supposed to send, maybe

X-Locale: de

. Now, for the test and pact this argument does not matter, any valid country-code would suffice,

fr

for example. Should the pact on consumer side now explicitly demand

de

, using

headers("X-Locale", "de")

or let the provider decide on this with

headerFromProviderState("X-Locale", "${anyValidLocale}", "de")

? This question goes even further. Lets say we have to send a complex DTO body, but for the particular pact only one value in it actually matters. Should the rest of the DTO be given by the provider state or should the consumer just specify the full DTO, even though majority of it doesnt matter? Essentially, I am looking for ways to signal to the provider that something was not picked due to any particular reason, but could be anything. So that the provider clearly knows which part of the contract is actually important to the consumer.

as a starting point, I think this principle still stands, and the one directly beneath https://docs.pact.io/consumer#only-make-assertions-about-things-that-will-affect-the-consumer-if-they-change

the thing is, from a consumer POV some values of a request are actually important to be the way they are. and others could be anything that fits. for example, lets say the request has to send a positive value in the body

"value": 5

now, the consumer pact could be something like "when sending a positive value, you respond with 200" who is supposed to decide on a value here? the consumer? the provider? and if the consumer picks one, how to signal that they could also have picked 10 or 20, i.e. that they do not really care? for a response, i would just use a lose regex matcher, but afaik for the request part the consumer is supposed to be as strict as possible, no?

now, the consumer pact could be something like “when sending a positive value, you respond with 200”

who is supposed to decide on a value here? the consumer? the provider?

I would default to the consumer, unless there is a good reason.

for a response, i would just use a lose regex matcher, but afaik for the request part the consumer is supposed to be as strict as possible, no? (edited)

Yes, ideally you don’t have matchers on the request unless you really need to (the matchers are only checked on the consumer test, not on the provider side - in case that wasn’t clear). I wouldn’t get too hung up on some of these things though. Occasionally that will border on a functional test, but that’s OK, the lines aren’t always clear and bright. See also https://docs.pact.io/consumer/contract_tests_not_functional_tests. If it is important that the “positive number” or “date in the past” scenario is checked, then it should be covered (and specified from the consumer).

i could use

valueFromProviderState

to let the provider pick one. but it doesnt feel like the right tool for the job

I would tend to use this function sparingly, and only give more work to the provider if necessary.

makes sense. gonna find the sweetspot then, thank you for the input 👍

I’m keen for other thoughts on this too!