Feature/early mismatch

[Stepami]

Description

• added new method WireMock.RequestBuilders.IRequestBuilder.WithEarlyMismatch
• covered feature with tests (WireMockServerTests.Grpc and RequestMessageCompositeMatcherTests)

Method WithEarlyMismatch sets selector which chooses matcher to return immediate mismatch during mapping processing.
Selector is a Func delegate run on available matchers.

References

Closes #1442

[StefH]

I understand the code, and this works, however it needs deep understanding of the code.

A better approach could be to introduce an enum

public enum MatcherType
{
    Path = 0,

    Url = 1,

    // ...
}

And pass this to the WithEarlyMismatch(MatcherType.Path).
Internally the code can translate that enum to a real request matcher.

Also this logic could be added to the Mapping + MappingModel.

[Stepami]

@StefH I agree that design with delegate is a bit complicated for an arbitrary user. I do like the idea with type discriminator for RequestMatchers! But i don't think that enum is a solid choice in this situation.

My concern is that IRequestMatcher is a public interface, which means i can make my own implementation outside of WireMock. Thus, i would like to be ensured that WireMock is capable to support my custom RequestMatcher in a way that i can introduce new RequestMatcherType outside of library. enum doesn't allow that as it's not extensible.

I would make RequestMatcherType as the Value Object with predefined instances rather than enum. It would allow instantiate new types outside of library's source code.

The part about logic addition to Mapping + MappingModel is unclear to me

[StefH]

I think this design could be a possible solution:

1. Add a Name property to IRequestMatcher, just as I did for IMatcher.

2. Just call the WithEarlyMismatch with a string like "Path".

3. Now the internal logic will loop all request matchers on a mapping and take the one with matching name.

4. In case you use a custom matcher like "MyNamespace.MyMatcher", then use TypeLoader.TryLoadStaticInstanceByFullName<IRequestMatcher>("MyNamespace.MyMatcher"); to resolve it.

5. For step 4, I'm not sure this will work 100%, but I don't know if there any users who do build their own RequestMatcher.

---

The part about logic addition to Mapping + MappingModel is unclear to me

It's also possible to define the mappings using a MappingModel (which can you can post as json) to WireMock.Net (https://wiremock.org/dotnet/request-matching/#json-example)
So this new logic should also be added to the mapping, so that you can configure this new functionality using the MappingModel.

[Stepami]

@StefH I investigated the code and decided to implement the idea with enum. There are two big reasons for this:

1. No info on your side about custom request matchers
2. Property string Name is reserved in the Headers and Cookie matchers where it has different meaning. Thus i decided to avoid breaking change