starred/WireMock.Net-wiremock
1
0
Fork 0
mirror of https://github.com/wiremock/WireMock.Net.git synced 2026-01-11 14:20:29 +01:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Question: WithBody can't be used with multiple matching rules? #191

New Issue
Closed
opened 2025-12-29 14:24:41 +01:00 by adam · 7 comments
adam commented 2025-12-29 14:24:41 +01:00
Owner
Copy Link

Originally created by @PkAIR on GitHub (Jul 22, 2019).

Originally assigned to: @StefH on GitHub.

Stuck with a question: is it possible to use several matching rules for request body?

WithParam(...) from IParamsRequestBuilder as well as WithHeader(...) from IHeadersAndCookiesRequestBuilder support smth like:

foreach (var matcher in ParamMatchers)
{
     request.WithParam(matcher.Key, MatchBehaviour.AcceptOnMatch, matcher.Value.ToArray());
}

since it intakes key.

But for WithBody(...) from IRequestBuilder can't do smth similar.

How can I deal with several matching rules for request body?

Originally created by @PkAIR on GitHub (Jul 22, 2019). Originally assigned to: @StefH on GitHub. Stuck with a question: is it possible to use several matching rules for request body? **WithParam(...)** from **IParamsRequestBuilder** as well as **WithHeader(...)** from **IHeadersAndCookiesRequestBuilder** support smth like: ``` foreach (var matcher in ParamMatchers) { request.WithParam(matcher.Key, MatchBehaviour.AcceptOnMatch, matcher.Value.ToArray()); } ``` since it intakes **key**. But for **WithBody(...)** from **IRequestBuilder** can't do smth similar. How can I deal with several matching rules for request body?
adam added the question label 2025-12-29 14:24:41 +01:00
adam closed this issue 2025-12-29 14:24:42 +01:00
adam commented 2025-12-29 14:24:43 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jul 22, 2019):

Good point.
I don't even know if multiple matchers is now supported in the interface?
Like:

"Body": {
            "Matchers": [
            {
                "Name": "JsonMatcher",
                "Pattern": "{ \"x\": 42, \"s\": \"text\" }"
            },
            {
                "Name": "JsonMatcher",
                "Pattern": "{ \"x\": 42, \"s\": \"stef\" }"
            }
            ]
        }

I'll have to check the code...

@StefH commented on GitHub (Jul 22, 2019): Good point. I don't even know if multiple matchers is now supported in the interface? Like: ``` js "Body": { "Matchers": [ { "Name": "JsonMatcher", "Pattern": "{ \"x\": 42, \"s\": \"text\" }" }, { "Name": "JsonMatcher", "Pattern": "{ \"x\": 42, \"s\": \"stef\" }" } ] } ``` I'll have to check the code...
adam commented 2025-12-29 14:24:43 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jul 22, 2019):

I've updated the code, can you take a look at the latest version at MyGet?
WireMock.Net.1.0.25-ci-11541.nupkg?

@StefH commented on GitHub (Jul 22, 2019): I've updated the code, can you take a look at the latest version at MyGet? ` WireMock.Net.1.0.25-ci-11541.nupkg`?
adam commented 2025-12-29 14:24:44 +01:00
Author
Owner
Copy Link

@PkAIR commented on GitHub (Jul 22, 2019):

@StefH Sorry for late notice. Yeah, will do tomorrow. I'm off for now.

Thank you for such a quick response though!

@PkAIR commented on GitHub (Jul 22, 2019): @StefH Sorry for late notice. Yeah, will do tomorrow. I'm off for now. Thank you for such a quick response though!
adam commented 2025-12-29 14:24:44 +01:00
Author
Owner
Copy Link

@PkAIR commented on GitHub (Jul 22, 2019):

Hi @StefH

Nah, couldn't wait till tmr.

At a first glance I was able to get it working. I succeeded in building a valid mocking template with array of BodyMatchers:

[ { "Guid": "9af78b09-28b5-465a-80d0-c0b3261b2c64", "Scenario": "Test For EnterOrder", "SetStateTo": "1", "Request": { "Path": { "Matchers": [ { "Name": "WildcardMatcher", "Pattern": "*/EnterOrder", "IgnoreCase": false } ] }, "Url": { "Matchers": [ { "Name": "WildcardMatcher", "Pattern": "*/EnterOrder", "IgnoreCase": false } ] }, "Methods": [ "POST" ], "Body": { "Matchers": [ { "Name": "JsonMatcher", "Pattern": "{\"testse\": 213123123}" }, { "Name": "JsonMatcher", "Pattern": "{ \"test\": 2133}" } ] } }, "Response": { "StatusCode": 200, "BodyDestination": "SameAsSource", "Body": "{\"resp\": 231213}", "Headers": { "test": "test" } } } ]

(pay no attention to jsons. I changed them as I could).

But then I noticed such behaviour.

Let's assume I have two body matchers and all of them are for instance JsonMatchers. One of it is totally correct (worked without array introduction) and the second one is some rubbish (as in json from above).

Then after making a request I see it passed even with one 'negative' result of matching as I think. Is it expected or not? Does work like - if at least one matcher succeeded then return given response?

@PkAIR commented on GitHub (Jul 22, 2019): Hi @StefH Nah, couldn't wait till tmr. At a first glance I was able to get it working. I succeeded in building a valid mocking template with array of **BodyMatchers**: `[ { "Guid": "9af78b09-28b5-465a-80d0-c0b3261b2c64", "Scenario": "Test For EnterOrder", "SetStateTo": "1", "Request": { "Path": { "Matchers": [ { "Name": "WildcardMatcher", "Pattern": "*/EnterOrder", "IgnoreCase": false } ] }, "Url": { "Matchers": [ { "Name": "WildcardMatcher", "Pattern": "*/EnterOrder", "IgnoreCase": false } ] }, "Methods": [ "POST" ], "Body": { "Matchers": [ { "Name": "JsonMatcher", "Pattern": "{\"testse\": 213123123}" }, { "Name": "JsonMatcher", "Pattern": "{ \"test\": 2133}" } ] } }, "Response": { "StatusCode": 200, "BodyDestination": "SameAsSource", "Body": "{\"resp\": 231213}", "Headers": { "test": "test" } } } ]` (pay no attention to jsons. I changed them as I could). But then I noticed such behaviour. Let's assume I have two body matchers and all of them are for instance **JsonMatchers**. One of it is totally correct (worked without array introduction) and the second one is some rubbish (as in json from above). Then after making a request I see it passed even with one 'negative' result of matching as I think. Is it expected or not? Does work like - if at least one matcher succeeded then return given response?
adam commented 2025-12-29 14:24:44 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jul 23, 2019):

Currently the logic is for all (~almost all) matchers is that the matchers are used as an OR.
So the best matching score from multiple matchers is used.

If required in future, I can also implement an AND, but for that I need to change the API and the JSON.

@StefH commented on GitHub (Jul 23, 2019): Currently the logic is for all (~almost all) matchers is that the matchers are used as an `OR`. So the best matching score from multiple matchers is used. If required in future, I can also implement an `AND`, but for that I need to change the API and the JSON.
adam commented 2025-12-29 14:24:44 +01:00
Author
Owner
Copy Link

@PkAIR commented on GitHub (Jul 23, 2019):

Got it, thanks. For now I don't see any reason for doing it.

Anyway, I'm happy with this change.

Do you have eta when it will be available in stable?

@PkAIR commented on GitHub (Jul 23, 2019): Got it, thanks. For now I don't see any reason for doing it. Anyway, I'm happy with this change. Do you have eta when it will be available in stable?
adam commented 2025-12-29 14:24:45 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jul 23, 2019):

In some hours.

@StefH commented on GitHub (Jul 23, 2019): In some hours.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
bug
doc
doc
duplicate
feature
feature
invalid
pull-request
Mirrored from GitHub Pull Request
 question
wontfix
No Label question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#191
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?