httpclient-interception
httpclient-interception copied to clipboard
WithResponseHeaders and WithContentHeaders overloads
Is your feature request related to a problem? Please describe.
I have an extension method which allows me to register responses for intercepted requests such that each subsequent request that matches, returns a different response content. I do this by using a closure of a Counter
object, which gets incremented using WithInterceptionCallback
, as follows:
[EditorBrowsable(EditorBrowsableState.Never)]
static class HttpRequestInterceptionBuilderExtensions
{
public static HttpRequestInterceptionBuilder WithJsonResponses<T>(
this HttpRequestInterceptionBuilder builder,
Func<int, T, CancellationToken, Task> callback,
T[] content,
JsonSerializerOptions? options = null)
{
var counter = new Counter(content.Length);
T item = default!;
return builder
.WithInterceptionCallback(async (_, cancellationToken) =>
{
counter.Increment();
item = content[counter.Value - 1];
await callback(counter.Value, item, cancellationToken);
})
.WithMediaType("application/json")
.WithContent(() =>
{
if (item is Exception exception)
throw exception;
return JsonSerializer.SerializeToUtf8Bytes(item, options);
});
}
class Counter
{
readonly int _maxValue;
public Counter(int maxValue) => _maxValue = maxValue;
public int Value { get; private set; }
public void Increment()
{
if (Value == _maxValue) return;
Value++;
}
}
}
I would like to do the same for the response headers and content headers as well. This requires new overloads for WithResponseHeaders
and WithContentHeaders
, and some associated code changes.
Describe the solution you'd like
New overloads for WithResponseHeaders
and WithContentHeaders
, which allow passing a Func<IDictionary<string, ICollection<string>>>
.
Describe alternatives you've considered
No alternatives exist.
Additional context
The reason for requiring different responses to the same request is that the API being "mocked" is one that returns data which changes over time. My test suite is set up so that I can verify this behaviour.
I've pushed up a commit with a prototype/proof-of-concept of how this might work here: https://github.com/martincostello/httpclient-interception/commit/fb9440dbe550eb0a9d77d388069da5fd4523b97a
Let me know if this would address your use case, and if it seems workable I can look at fleshing it out.
Thanks @martincostello!
That looks perfect for my use case, and it seems like a very elegant solution. Perhaps some async overload might be useful (like there already is for WithContent
)? I don't currently need it to be async-friendly though, so it could be omitted if you don't think it's worth it.
Cool - glad it works for your use case.
I left out async to start with to get some fast feedback, however given the current internal design I don't know if it could be easily added or not. I'll consider it, but leave it out if it requires too much rework - it could always be added at a later date in a new major version if there's demand for it.
I'll look at circling back to this change and fleshing it out some time this week. Once I do that I'll push up a pull request, and you should be able to validate it via a preview NuGet package via the GitHub Actions CI to validate it before it goes into a release shipped to NuGet.org.
Thanks @martincostello.
I've tested it and it works great!
Thanks - I'll come back to finishing this off and prepping a release including the change next week when I'm back in the office.
This change is now available from NuGet.org.