mirror of
https://github.com/wiremock/WireMock.Net.git
synced 2026-01-11 14:20:29 +01:00
Feature: Add JsonMatcher to support Json mapping #110
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @DavidKorn on GitHub (Jun 25, 2018).
Originally assigned to: @StefH on GitHub.
I'm mocking an API that makes heavy use of JSON objects in the request body, and I'm trying to create readable static mapping files for requests with different JSON bodies.
I was hoping to leverage the Reqest's BodyAsJson tag to just define the exact request body I'm wanting to match., rather than create long JsonPathMatcher pattern strings for the Request Body.
This seems to parse ok, but isn't working as I expected. I think under the hood WireMock.Net is deserializing the JSON in the mapping file and in the request, and then doing reference equality on the two resulting objects to see if they are the same, which naturally they are not.
Is there a better way to use BodyAsJson in static mapping files, or maybe a workaround?
@StefH commented on GitHub (Jun 25, 2018):
Correct, the
JsonPathMatchercan only be used when you want to match a json path pattern.Solution would be:
JsonMatcherorJsonExactMatcher<-- preferredJsonPathMatcherto accept a json object as pattern@StefH commented on GitHub (Jun 25, 2018):
See NuGet : WireMock.Net.1.0.4.1
And wiki: https://github.com/WireMock-Net/WireMock.Net/wiki/Stubbing-and-Request-Matching#json-jsonmatcher
@DavidKorn commented on GitHub (Jun 25, 2018):
I'm happy to work on a contribution to fix improve this. I think the shortcoming with using the MatcherModelMapper is that the pattern is a string. A static mapping user would have to escape out all the double-quotes and do the whole JSON on one line, which really hampers readability.
Would you allow a BodyAsJson property on the static mapping Request definition that just took an object (and not a Matcher definition)? So this would look just like the BodyAsJson in the static mapping Response. It would trigger an exact JSON serialization comparison with the incoming request body. This would be very clean to read and alter in the mapping file, and I think it would well suit a common use case. If more flexibility is needed, the JsonPathMatcher can be used instead.
Further, if the proxy recorder came across a serializable JSON body in the request, it could record this as a BodyAsJson property for the static mapping file rather than translate it into an ExactMatcher as it currently does. (The drawback we're seeing for the ExactMatcher is that if the recorded call indented the JSON body but a later caller doesn't, we don't get a match.)
@DavidKorn commented on GitHub (Jun 25, 2018):
LOL, by the time I got that comment written you'd already implemented JsonMatcher! WOW!
@DavidKorn commented on GitHub (Jun 25, 2018):
So this is a nice improvement, thanks so much for the rapid response. I'm really jazzed about this tool, and I much appreciate your continuing work to enhance it.
I'd still be interested in support for BodyAsJson object definitions in the Request mapping, for the reasons I had outlined above. If I came up with a PR, would you be open to incorporating that?
@StefH commented on GitHub (Jun 25, 2018):
Further, if the proxy recorder came across a serializable JSON body in the request, it could record this as a BodyAsJson property for the static mapping file rather than translate it into an ExactMatcher as it currently does. (The drawback we're seeing for the ExactMatcher is that if the recorded call indented the JSON body but a later caller doesn't, we don't get a match.)
Good point. Can you make new issue, or maybe an PR?