Kinda related to this thread, but does pact-jvm have a modern way to select multiple consumers for a given provider test? i.e. if a provider has a known set of consumers (rather than just one) we would like to run all tests for those on the same class if possible. Using

@Consumer

only allows one consumer per test class. I see that

@PactBroker

annotation has the

consumerVersionSelectors

field, but that is apparently deprecated. The

@PactBrokerConsumerVersionSelectors

method with

SelectorBuilder

doesn't appear to have any way to select multiple consumer names. Is there a better approach?

You can provide raw json with

rawSelectorJson(json: String)

and pass the consumer name selectors https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors#advanced it takes an array of selectors, so you can provide scope your selector with the consumer name

Is this something that will be officially supported for a while? Just a little hesitant to use the raw JSON since we lose some of that first class support

https://docs.pact.io/implementation_guides/jvm/provider/junit#providing-the-raw-consumer-version-selectors-json it’s in the docs, you can check the commit history

Yeah I'm not opposed to submitting a PR upstream if thats something you all would support 🙂

ps. I don’t live in the pact-jvm world much, @uglyog is our jvm dude, you can always raise an issue on the repo and we can see if there would be support for it 👍

Thanks! On a side note, do you have any thoughts on the linked thread above?

By default, a provider test will verify the pacts for all consumers. This is by design. You shouldn't need to specify the consumers.

In our case though we were running into an issue where we just split up provider tests to different classes. So we had something like:

ProviderATest

(consumed by

consumer-a

) and

ProviderBTest

(consumed by

consumer-b

) in the same monolithic project, each with their own states since they're pretty disjoint features. Pact was then complaining that

ProviderATest

didn't have the states that

ProviderBTest

verified and vice versa

I'll be honest Si, I work better with visuals once there are more than a few hops in our scenario and a big thread. I also haven't had time to dip into that other thread yet. How artsy are you feeling? Do you think you could roughly draw up the chonkie boi. It might give us a better working base to get in the head space. If your crayolas are a bit blunt, you could whip up a sample repo? I don't mind diving into code.

Does this bad drawing help at all @Yousaf Nabi (pactflow.io) 😆 All of the provider tests within the same monolith are separate classes with their own unique set set states since they are all for different consumers but they all have the same

@Provider(Monolith)

annotation

(@Phillip Lo and I are working on the same project btw)

perfect! could you consider the three providers in the monolith to be of separate concerns, they just live in the same home, say name them by convention monolith-provider-a. assume they all deploy together so they would share the same version number. at the point of deployment for the monolith you would check can i deploy with repeated arguments for each names monolith-provider-x

can you explain this line

the only pain point i see if when you want to deploy the mono but one of the services inside isn't compat.

so monorepo is made up of say 3 micro providers. they each talk to one, different consumer. the monorepo has a single version number of which you wish to deploy into an environment. that version number would be shared around the 3 micro providers ( as the version number relates to the code you are releasing and they all comprise in a single repo ) if one of the micro providers in the mono repo isn’t compatible with its consumer, none of your monorepo can be deployed, blocking the other micro providers. i am using a term micro provider here loosely, to represent your provider test class a, b and c in your diagram. i assume these aren’t that related and are effective distinct providers from each consumers perspective?

yea, unfortunately they could be distinctive but are also many times related and could actually be the exact same "microprovider"

hmm. so there is the idea of provider states with params in v3 and v4. could this allow the idea of some kind of shared state and then a permutation based on a particular clients needs ( as informed by the state params )