Skip to content

Refactor the assertion mechanism (was: Add description of the requests that are made) #204

@dnperfors

Description

@dnperfors

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...

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions