oatsoda / teepee Goto Github PK

https://learn.microsoft.com/en-us/dotnet/api/system.net.http.socketshttphandler?view=net-7.0#remarks

dotnet/runtime#35212 (comment)

Currently using default settings, but will need to mock different settings - formatting, casing etc.

Authentication? If prod code normally uses Delegating Handlers, then need to allow Tracking Handler to sit AFTER this. Is this where DI needed?

There could be more help for when Requests don't match - rather than having to check which parts didn't match.

e.g. if you configured URL, Query, Headers and Body for matching, then if it doesn't match, it would be faster for developers to see which part failed to match.

This should be relatively simple for cases where you are using a Tracker - as the exception in the tests can simply expand on the details of what matched. The ShowFullDetailsOnMatchFailure option already configures the Tracker exceptions to list all of the calls that were made, so you can compare against the match rule that failed.

However...

Largely, TeePee is expected to be used without the Tracker, as implicit testing (e.g. configured GET response and validate the the business logic that uses it, works) is the primary case.

So potentially, failure to match isn't using a Tracker, so having the details at the point of attempting to match would make more sense. But, it's quite likely you might not bother to mock all of the HTTP calls for a SUT if you are testing one part - so having TeePee execute some backtracking to determine reasons for the failure to match could be very heavy and cause a lot of log outputs.

So either it needs to be more clever, or there needs to be some setting - but turning a setting on/off could be painful.

Require match to have been set up else fail all non-matching requests.

Refit has it's own registrations for DI and could make injecting the Http Handler difficult (reflection to get HttpClient registration instance)

Perhaps need Extensions for this.

May need to look at DI coverage in unit tests also to make this worthwhile.

https://learn.microsoft.com/en-us/dotnet/core/extensions/logging-library-authors#prefer-source-generated-logging

WasCalled or WasNotCalled exceptions to contain a list of all calls made.

See https://github.com/oatsoda/TeePee/blob/main/TeePee/Extensions/HttpRequestMessageExtensions.cs - it has a rule exception for the String content, but it should also be excluding FormUrl - i.e. only if it is actually Byte content should it be using the base64 rule.

Something like this?

.RequestFor("https://some-url")
.Responds()
.WithBody(new { Blah = "thing" })
.WithStatus(HttpStatusCode.Ok)
.ThenResponds()
.WithStatus(HttpStatusCode.Conflict);

Is it just a case of requiring DI to be used for tests?

If so, examples required.

If you've setup a match rule, but then want to change its response status/body/headers etc. then currently it doesn't work because it arbitrarily uses the first one it finds.

I'm not sure we can deal with this at build-time, so probably at match-time we should use the most recent, most specific rule that matches.

If there was a timestamp for when the rule was added, we could be explicit about the ordering.

Though #7 would deal with Trackers that don't match, it might also be useful to have better logging when matches aren't made without the Tracker.

Perhaps settings required for:

• Show Full Body of requests
• Show all Setups (and their Full Body values)

Perhaps also something like "URL matched, but Body didn't" - i.e. more granular reasons why matches weren't made.

If URLs match but not Body, then perhaps it's more helpful to default to log more data - on the assumption it's not just been ignored, but that it's accidental?

HttpClientFactory

• Basic - depend on IHttpClientFactory - call CreateClient() each time
• Named - as per basic, but CreateClient takes name
• Typed - depend on HttpClient - injected by DI (transient)

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-3.1#consumption-patterns