https://pact.io logo
Join Slack
Powered by
we have a monolith owned by multiple teams with ma...
# general
p
we have a monolith owned by multiple teams with many different endpoints etc. that is acting as a "provider" in the contract testing world. So far we've found that pact wants to verify every state for every contract that is in the broker against this monolith. That obviously doesn't make sense because each consumer has their own set of test states depending on the endpoints that they use so the one way we've figured out how to tell pact to only care about the correct States is to add something like
Copy code
@PactFilter(
        value = {"^\\/myendpoint\\d+/.*"},
        filter = ByRequestPath.class)
to the top of the respective provider test class. Is this the correct way to go about this or is there something else that we might be missing that is a little more userfriendly?
A little more context, since the monolith has so many "services" inside of it, there will be many provider tests each in their own class owned by different teams instead of one large provider test with every test state in it since they are all unrelated to each other
t
Generally, no, you wouldn’t filter the states
I don’t think I understand your use case. Different teams own different parts of the monolith?
You could do different tests per consumer?
It sounds like you need your provider team(s) to agree on the states they are exposing to consumers and to communicate those to the consumer team(s)
p
Yep, different teams own different parts of the monolith with the potential of different teams owning different endpoints within the same controller (yes I know...) Also, we went ahead and updated the provider tests to tie them to a specific consumer with something like this at the top of the test class.
Copy code
@Provider(MONOLITH)
@Consumer(MICROSERVICE)
however, from what I can tell, you can't have a list of consumers so we'd kinda be duplicating each test for each pair of monolith to consumer. Does that sound right?
t
This sounds like it’s more a #C9UN99H24 question, but you should be able to have multiple consumers in one test. Have a look at the documentation for consumer version selectors for pact jvm (I am not familiar)
👍 1
p
we were filtering also since the same endpoints in the monolith are not all used by every consumer. one consumer could be using one endpoint while another endpoint is used by another consumer
but by default pact was trying to verify every state with every contract
t
It should only verify the states in that contract, right?
p
Contract 1: StateA Contract 2: StateB, StateC Provider test 1: StateA Provider test 2: StateB, StateC without the above it would try and verify stateB and stateC against contract 1
t
You shouldn’t need to think of it in terms of states or endpoints
The states are part of the setup for the contract
Not the verification
You don’t verify states
If provider test 1 doesn’t see contract 2 it should not try to set up the states from contract 2
p
Yea, I think that makes sense when the providers are different but in this case the provider for both contracts are the same (the monolith)
it is possible im confusing myself at this point though 😄
t
I think you are
But that’s ok! There’s a lot happening when you first start using it
🙌 1
But that’s ok! There’s a lot happening when you first start using it
So, the states are setup per interaction. Contracts are made of interactions
If the test doesn’t use a contract, the interactions in that contract won’t fire their state setups
If the test doesn’t use a contract, the interactions in that contract won’t fire their state setups
p
Is that true even if both tests are annotated with the same @Provider
t
I don’t know how tests select contracts in pact jvm
But, telling it only the provider will select all the contracts
Select contracts For each contract, For each interaction Setup state Test interaction Teardown state
^ it’s kinda like that
p
got it. that makes sense
t
Sorry, teardown state, not teardown interaction
In general, you should not filter by states, because it will mean that you might partially verify contracts
👍 1
I don’t know if Pact jvm will let you publish if you have only done a partial verification, but the broker only knows about yes or no. It doesn’t know about parts of the contract
So if you filter by state, and you are able to publish success, you lose the safety that Pact is supposed to give you
👍 1
y
I don’t know if Pact jvm will let you publish if you have only done a partial verification, but the broker only knows about yes or no. It doesn’t know about parts of the contract
this is something i need to check both in the ruby and rust core. i agree it could lead to a state of false confidence. i’ve replied in another thread but i wonder if everything being named as the same provider in the monolith is the issue. it would help you understand of all the endpoints on the big monolith, these few are being used for these scenarios as shown in a pact
sharing provider states with consumers especially as you scale is challenging and i don’t believe there is an elegant solution at least afforded to you by the pact tooling. i think this would be a good area where we could make the states more available or searchable or something in the broker
it is possible im confusing myself at this point though 😄
heh that is definitely okay, we do it all the time. 🌮 for @Timothy Jones for being super polite, friendly and awesomely helpful as always
Open in Slack
PreviousNext
Powered by