oatsoda / teepee Goto Github PK
View Code? Open in Web Editor NEWA fluent API to configure HttpClients for unit testing.
A fluent API to configure HttpClients for unit testing.
Error Message:
System.InvalidOperationException : Operations that change non-concurrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The collection's state is no longer correct.
Stack Trace:
at System.Collections.Generic.Dictionary`2.FindValue(TKey key)
at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value)
at TeePee.Refit.ServiceCollectionExtensions.GetRefitHttpFactoryName[T]()
at TeePee.Refit.ServiceCollectionExtensions.AttachToRefitInterface[TRefitInterface](IServiceCollection serviceCollection, TeePee teePee)
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.
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:
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.