https://pact.io logo
Join Slack
Powered by
Hi everyone, I am pretty new to Pact (or to CDCT i...
# general
i
Hi everyone, I am pretty new to Pact (or to CDCT in general) and have a question . We have a REST API where we must give an identifier as a query parameter in order to fetch the details about that "product". We as a consumer are not interested in the details of a particular product but in general about the form and structure of the response body. How do I define that in my consumer test? Can I convey this message by defining a matching rule for the query parameter and saying that I am just sending you an integer? The provider can then just send me the details about any product because I am only interested in it's structure and the data types.
m
You would usually use a “provider state” to convey this
“given a product with ID 10” for instance, would be the state. When the provider verification runs, it can insert a record with ID 10 in the database before the test runs (the SDK has facilities for this) and then when the verifier executes the test, it should pass
In general, the answer about form/structure is true - but when Pact issues the call to the provider, it needs an example to send - what should it send, if not the one defined in the pact file?
Some languages have a way for the provider to override that at the provider end using a matcher (in JS it’s called 
fromProviderState
).
i
Thanks for the quick reply Matt. The form and the structure would be defined as the expected body in the CT. What we want to avoid here is that 20 different consumers doing a form and structure test but giving 20 different IDs for which then provider has to maintain 20 different provider states.
👍 1
m
of course.
So the response body is easy - that’s what matchers are for
You could apply a matching rule to the query string, but that’s only relevent for the consumer test - in general matchers that are targeted at the consumer I’d suggest is a code smell (it shows you can’t control your consumer code very well)
What we want to avoid here is that 20 different consumers doing a form and structure test but giving 20 different IDs for which then provider has to maintain 20 different provider states.
for this, one suggestion would be to suggest re-using state names across tests. From a provider’s perspective, you can simply reject (by never successfully verifying) a pact test that has states you don’t wish to support, and communicate that intent in some way. We’re thinking about how we might be able to do that within the PactFlow experience to help aid the process, but good old fashion talking to each other / slack etc. is probably workable in most contexts
Are you working in a particular language?
i
I think the fromProviderState sounds interesting if I understand it well. So with that a provider can override the identifier with the one that it has created once in it's provider state to verify all the consumers with a particular use case.
👍 1
We use Java and Kotlin together with Spring Boot.
👍 1
m
I would still encourage the use of named states, because they make the test intent clearer.
i
With named states you mean to say that the consumer should convey an exact ID that it wants for the test? So basically not using fromProviderState?
m
do both
use the named state, because it shows the intent of the test (i.e. an important pre-condition), but use the matcher as really that’s to help the provider execute/maintain the tests
👍 1
i
Thanks Matt. Do you have an example / link for 
fromProviderState
in Python too? One of our teams is using Python and I can't find anything about it in the Python docs.
m
I don't believe python has that support yet. If you follow the pinned issues there you'll see that's a work in progress and not too far away for a new major release
Open in Slack
PreviousNext
Powered by