Same request but with different responses about httpclient-interception HOT 4 CLOSED

Thanks for the question - this is possible, but there isn't an explicit example of this in our Examples unit tests. There is a unit test elsewhere that shows this sort of thing though:

https://github.com/justeat/httpclient-interception/blob/961bfc07a358f58ed2d1af6dace413ef826470e7/tests/HttpClientInterception.Tests/HttpRequestInterceptionBuilderTests.cs#L55-L97

For your example, if I'm understanding it correctly, you'd want to do something like this pseudo-code:

// Create an empty list
var items = new List<MyObject>();

// Register the GET and POST requests
var options = new HttpClientInterceptorOptions();
new HttpRequestInterceptionBuilder()
    .ForGet()
    .ForUrl("http://localhost/items")
    .WithJsonContent(items)
    .RegisterWith(options);

new HttpRequestInterceptionBuilder()
    .ForPost()
    .ForUrl("http://localhost/items")
    .WithStatus(HttpStatusCode.Created)
    .RegisterWith(options);

// Your code to do the first GET and POST goes here

// Add an item to the list - the GET registration is
// using the object by reference, so any mutations to
// it will be observed by subsequent requests which
// match the registration for the builder using it.
items.Add(new MyObject());

// Your code to do the second GET goes here, which
// should return the list with the single item in it.

If you need to inspect the object that was POSTed in some way, then you could use the WithInterceptionCallback() method to inspect the request body and mutate the list from a callback. This test shows the use of a callback:

https://github.com/justeat/httpclient-interception/blob/961bfc07a358f58ed2d1af6dace413ef826470e7/tests/HttpClientInterception.Tests/HttpRequestInterceptionBuilderTests.cs#L744-L781

Another possible approach is to use scopes, and change the behaviour of a registration as a test progresses, similar to this example:

https://github.com/justeat/httpclient-interception/blob/961bfc07a358f58ed2d1af6dace413ef826470e7/tests/HttpClientInterception.Tests/Examples.cs#L362-L395

Let me know if either of these answer your question, and I'll add a new example to the tests to make this behaviour a bit more discoverable.

from httpclient-interception.

Thanks for the insightful reply. I can see, I left out some - probably - valuable information:

• I am using bundles
• I am testing a request to an API that aggregates responses from other APIs - it's the latter that I am intecepting. So my tests wont be able to manipulate midway.

I created an approach where I, using another custom delegate handler would add a "X-TestIndex" header to each request with an incremental value per call. That I would then match uniquely in my bundle file with the "requestHeaders" properties. But, for some reason, I haven't figured out yet, it won't match.

from httpclient-interception.

Thanks for the clarification.

Bundles aren't able to support the same "mutations" functionality that I described as there's no code/object references to back them up, as everything is ultimately just a string from the parsed bundle file. This is sort-of by design, as they're intended to solve the simple use case where you play back the same things repeatedly/often where it's easier to define in a file rather than repeat test setup in code.

For the code-based approach, there's also the concept of "priorities" which can be mixed with custom matching to have an order of precedence so you can do fallback behaviours.

https://github.com/justeat/httpclient-interception/blob/961bfc07a358f58ed2d1af6dace413ef826470e7/tests/HttpClientInterception.Tests/Examples.cs#L570-L598

What you might be able to do is have some "defaults" in your bundle file, and then "layer on" an additional registration in code with a higher priority that can conditionally override the response configured in the bundle with a different one based on a predicate you define.

Your incrementing header approach sounds like it should work though. If you can share some code for what you're trying to do with it, I might be able to see what the problem is.

from httpclient-interception.

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from httpclient-interception.