-
Notifications
You must be signed in to change notification settings - Fork 0
Description
When an assertion fails, it is not always clear which request are actually made. This requires that you debug a test instead of reading the message.
Besides that it is a kind of mismatch of methods that you need to use and most of them have overloads for the number of requests that are made with the specific conditions.
All in all, it seems better to improve the whole assertion part of TestableHttpClient and make things easier.
Take the following example:
testableHttpClient.ShouldHaveReceivedRequestsFor("https://httpbin.org/post", 1).WithHttpMethod(POST, 1);
This is very verbose and can be shortened to:
testableHttpClient.Received(1).Post("https://httpbin.org/post");
Then there could be overloads for testing the content as well:
testableHttpClient.Recieved(1).Post("https://httpbin.org/post", "*hello*");
Testing for headers happens in the same way as before:
testableHttpClient.Received(1).Post().WithHeader("Authorization", "Bearer *");
Alternatively, Something like the UriPattern class for the HttpRequestMessage could work as well. It will make the whole experience more flexible and consistent with how requests are made as well:
HttpRequestMessagePattern sut = new()
{
Method = Value.OneOf("GET", "POST", "DELETE")
};
using HttpRequestMessage input = new(new HttpMethod(httpMethod), "https://localhost");
Assert.Equal(match, sut.Matches(input));
The biggest advantage is that you can just create a pattern for the complete request and test it in one go.
The disadvantage is that it could be more difficult to create the most sensible error messages...