Closed andrecarlucci closed 7 years ago
Hi there,
Thanks for the comments. This was done intentionally to make the registration set up easier to understand and reason with so that the path of least surprise was followed so context was easier to not accidentally bleed between tests, particularly if they get run in parallel.
A “nicer” way would be to register it as a singleton as you suggest, and have the tests re-register it as a transient, but I felt that was a bit too “advanced” for the documents to try and convey the ideas simply.
There’s also scenarios this type of usage makes tricker, such as not being able to use the BaseAddress
property of HttpClient
if you need to use more than one HTTP API in your application.
Point taken however, so I’ll add a few comments explaining that consumers way want to take their own approaches for exactly how they want to wire up HttpClient
.
I’ll make those updates either this evening or tomorrow and link the commit to this issue.
Thanks for the suggestion!
Resolved by #2.
Hi guys,
Thank you for sharing this really good idea, testing HttpClient is always a pain :)
One comment though: in the Sample and documentation the HttpClient is being registered as transient. That could cause a lot of problems with the server (performance, TCP/IP Port Exhaustion, etc.), as HttpClient is intended to be instantiated once and reused throughout the lifetime of an application or context.
Take a look here for more information: https://docs.microsoft.com/en-us/azure/architecture/antipatterns/improper-instantiation/
Cheers!