HttpTest: Set up responses depending on the call being made

[tmenier]

Flurl's current testing features allow you to fluently build up a queue of fake responses like this:

httpTest
    .RespondWith(...)
    .RespondWith(...)
    .RespondWith(...);

These responses are guaranteed to return to the test subject in same order that the Flurl requests are sent, but that's not always determinate, and there have been requests to allow configuring responses based on the call made, particularly the URL.

3.0 introduces filtered test setups. The example above will still work for general cases where filtering isn't needed, or when no filters match. Here is a fairly comprehensive example demonstrating just about all of the new possibilities:

httpTest
    .ForCallsTo("*.api.com*", "*.test-api.com*") // multiple allowed, wildcard supported
    .WithVerb("put", "PATCH") // or HttpMethod.Put, HttpMethod.Patch
    .WithQueryParam("x", "a*") // value optional, wildcard supported
    .WithQueryParams(new { y = 2, z = 3 })
    .WithAnyQueryParam("a", "b", "c")
    .WithoutQueryParam("d")
    .WithHeader("h1", "f*o") // value optional, wildcard supported
    .WithoutHeader("h2")
    .WithRequestBody("*something*") // wildcard supported
    .WithRequestJson(new { a = "*", b = "hi" }) // wildcard supported in sting values
    .With(call => true) // check anything on FlurlCall
    .Without(call => false) // check anything on FlurlCall
    .RespondWith("all conditions met!", 200);

You can add as many filtered setups to a test as you want, each beginning with a new call to httpTest.ForCallsTo(...).

Closely related is #225, the much-requested ability to selectively allow real HTTP calls to be made within a test. The example is a little buried in that issue so I'll repeat it here:

httpTest.ForCallsTo("*.api.com*").AllowRealHttp();

[tmenier]

Now available to test: https://www.nuget.org/packages/Flurl.Http/3.0.0-pre2

[michbushi]

that looks awesome! Any chance to add an "invisible proxy" mode; such as all the HttpTest-matched responses would return the mocked responses as configured, but for all unmatched calls, would actually call the underlying api and return the real response?

[tmenier]

@michbushi Yep, that's covered by #225, which is so closely related that I added an example to this issue's description.

[APIWT]

Thank you so much for this enhancement! Do you have a pulse on when 3.0 will be released?

[tmenier]

@APIWT I don't have an estimate yet. There's a fair amount more I want to do before I commit to no more breaking changes, and my available time is limited. What I've been telling people is that I consider these prereleases to be as stable and production-ready as any other release, the only difference being that there can and will be additional breaking changes. But I track them carefully in the release notes, you're control of when you upgrade, and I don't anticipate more than maybe 2 or 3 more before I strip the -pre label and call it official.