New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support flexible matching in request path #80
Comments
You can do this with normal terms on the consumer side, but we'll need the generators (which are like terms for the provider) for doing it on the provider side. Eg. You can set up the mock service to match a request for any employee |
I'm trying to attempt this and failing :( I am trying to create a pact that will accept a query param with a UUID, and return a valid response. We are trying to load the pact, into My two tests, one using a regex matcher in query string and one in the path
The first test will generate this pact file
Which when loaded into the pact-stub-service, it returns this, and the pact is hardcoded to the value specified in the pact, rather than the regex
Using the 2nd test, it fails to match an interaction during the pact test, as when the request is received by the mock service used by pact-js, it strips the query off the path, and can't match
I have an example repo here You can run the tests with the following but please note that currently the 2nd test in
The pact-stub server will spin up and you will see the matching warning. if you send
We have had to switch to wiremock as an interim measure :( which makes me most sad. |
Background: the reason the query is a string in the pact is that initially, we threw away all the matching information and only stored the "actual" reified request in the pact (because the matching that takes place in the mock service was already done, and the stub service didn't exist at that stage). Later, we realised the matching info was useful info, so we added it in, as it was just an addition to the json, and would be ignored by the pact verification step. Changing the query string from a string to a hash would be a breaking change for the v2 specification, however. The code on the other side expects a string and not a hash. In v3, it has been changed to a hash, but only the v3 pact reading code has been done in the ruby, (and only the format change, not new features are supported) not the v3 writing code. Here is the code that parses the v2 request, and merges the matching rules into the request structure to create a tree of nested matchers. https://github.com/pact-foundation/pact-support/blob/master/lib/pact/consumer_contract/interaction_v2_parser.rb We're going to have to parse the query string, if it exists, and overwrite it in the request hash before it gets parsed into the |
Hey @bethesque started looking at this now, based on your comments, I am assuming your after something like in we need to
Been playing around and this is where I've got to
Hopefully I am on the right track? Happy to be corrected if I am going completely arse about face =D |
Is there anything that can be done to help move this forward? We've started running into this issue with matchers around query params not properly being reflected when we run pact-stub-service. |
@mikahjc trying to get my head back around this issue. Can you give me the exact scenario that's causing you problems? |
Ok, I think I've fixed it. Try upgrading and see how it goes. |
Seems to be working now. For reference, the scenario we were running into was described at the end of YOU54F's first comment: we could get the stub service to work by sending the exact query param + value defined in the contract in the request, but if you changed the value it would consider it not a match and return 500 even if it should match the given matcher in the contract. |
Feature request from 2017 Developer survey:
There was an issue on the pact-js repository that I can't seem to find.
The text was updated successfully, but these errors were encountered: