Skip to content
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 different request matchers #12

Open
otrosien opened this issue Jul 6, 2016 · 2 comments
Open

Support different request matchers #12

otrosien opened this issue Jul 6, 2016 · 2 comments

Comments

@otrosien
Copy link
Contributor

otrosien commented Jul 6, 2016

At the moment the path and query params need to match exactly (using WireMock "equalsTo" matcher).
Let's check if there is need for more sophisticated request matching.

@otrosien
Copy link
Contributor Author

Example: Matching on request body..

@mduesterhoeft
Copy link
Contributor

mduesterhoeft commented Mar 11, 2018

Currently #63 already addresses making request matching more flexible when it comes to the request URI.

Matching based on the request body is also interesting because it adds confidence that the request is valid and would work against a real server.

We could use jsonPath body matchers. This could look something like this:

"bodyPatterns" : [ {
      "matchesJsonPath" : "$.redirect_urls.return_url"
    }, {
      "matchesJsonPath" : "$.redirect_urls.cancel_url"
    }, {
      "matchesJsonPath" : "$.transactions[0].amount.total"
    }, {
      "matchesJsonPath" : "$.transactions[0].amount.currency"
    } ]

This would just match on the presence of the listed request fields. I think matching values does not really make sense in most of the cases.

Adding such matchers to the snippet would be relatively easy. The question is rather which patterns do we want to add?

  • add matchers for every field found in the request
    we parse the request body and convert the json into a list of json paths
  • use field descriptors that are used in requestFields
    so we add a matcher for every documented, non-optional field - this would require access to the request field descriptors. We could merge the requestFields and the wiremockJson snippet. So we could add a new snippet variant wiremockJsonAndRequestFields that takes a list of field descriptors, executes the request fields snippet and uses the field descriptors to add the matchers. Alternatively we could just take a list of FieldDescriptors and use this to generate the matchers

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants