Pluggable Matcher for Unit Testing

[rcollette]

I made the mistake of doing the following in my tests in more than a few places

.WithHeader("Authorization", $"SSWS ${_oktaToken}")

(Can you spot the Typescript habit?)

It was actually a quite big body POST with more than just this header not matching. Once I debugged into Util.MatchesPattern, it then became rather simple to determine what was not matching, using an online JSON diff tool.

Still, I think developers could be assisted here if we were able to plug in a matcher implementation that provides logging of specific object/JSON properties that are not matching (Fluent Assertions?).

I totally get you wouldn't want to take another library dependency or necessarily build out Flurl with an extensive level of Matcher/Logging capability, but it would be very useful to be able to plug in our own matcher behaviors, for testing only. Hence, making it pluggable is the request.

A possible challenge here is the fact that this code is all static, so I'm not sure of the implication across an entire suite of tests. Perhaps a global/static configuration of a matcher is a good thing, perhaps not.

[tmenier]

I totally get you wouldn't want to take another library dependency or necessarily build out Flurl with an extensive level of Matcher/Logging capability

Correct, but I think you could achieve this using an existing extension point. Namely, an extension method that might look something like this:

public static HttpCallAssertion WithJsonMatch(this HttpCallAssertion hca, string json) {
    return hca.With(call => {
        var diff = new MyDiffTool().Compare(call.RequestBody, json);
        if (!diff.Same)
            throw new Exception(diff.DetailedDescription);
        return true;
    });
}

The other advantage of an extension method is there's nothing to "configure" - it exists as a separate method that you just call in place of one of the others. Does this get you where you want to go or am I missing anything?

[rcollette]

This will work. Thanks.