https://pact.io logo
Join Slack
Powered by
Hi all, does anyone know if it is possible to add ...
# pact-js
n
Hi all, does anyone know if it is possible to add some matcher to the query path for the consumer test? I have a url that looks like 
/api/payments/v1/fx_rates/${some-fx-id}
and want the provider to be able to verify that the 
${some-fx-id}
is just some random string of numbers, I know of course that there are many matchers for strings and numbers, I was just unsure of how to implement a matcher to the url path. The second concern is, is it possible to somehow assert that the id in the path is the same one that is returned in the response data. When I send a request to that endpoint with say id of 5, then the body has a key value pair of 
{id: 5}
and I wanted to assert that the response body's id is the one that was provided in the request url.
t
As far as I know, you can’t do path matchers in Pact. However, this isn’t what matchers are for - a matcher is for data flexibility at the provider end, not for making sure that the consumer is conforming. You can think of a matcher as “I promise you that if you respond with data that follows this matcher, this particular test covers that case”
The second concern is, is it possible to somehow assert that the id in the path is the same one that is returned in the response data.
Yes. Put it in the expectation in the Pact. Eg,
Copy code
path: "/whatever/5"
  body: { 
     id: 5,
  }
m
You can definitely do Path matching
But it’s best practice not to
t
Huh. How do you specify it in the DSL?
m
Something like this:
Copy code
path: Matchers.regex("the regex", "/path/to/dynamic-bit")
t
hmmm
m
The type is 
string | Matcher<string>
y
This is from the pact js v2 matcher https://github.com/YOU54F/template-jest-pact-typescript/blob/889cc9e6b849108ee0f8bfb67d895b83978cc98c/src/pact/client/requestPathMatching.pacttest.ts#L33 But shows the difference between a flexible and rigid match on the client request.
The expected response body will be returned on the consumer test side, as long as you make the right expected request. I think this might be served better in the later interface with provider states with params maybe. I would expect a request with an id and setup my response matcher to have a like on the id that is returned in the response ( or just wrapped round the resp object ) Your own consumer client test should assert that the response body contains the same request id sent in the test, if that is important for you to test consumer side. ( something relies on that id ) From the provider side, with state params you might get a request path with x id, provider creates state with that and returns correct response to pact verifier with that id in. Pact verifier uses the setup matching rules to validate the response against the pact. A matcher of any number for id might not be what you want, as you could send an id of 5 and get an id of 17 and the pact verifier would go, yeah both numbers.
3 Views
Open in Slack
PreviousNext
Powered by