Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
When creating HttpTest in async setup, real calls made in unit test #375
I've found what I think is a bug in HttpTest. When the HttpTest instance is setup inside an async call, calls to GetAsync actually try to call the real url. There is a test project attached below. The async setup is needed for some db calls.
Here is a test example done in MSTest:
This results in this error:
If the setup method is changed to a non-async method (commented out line above), there is no error.
It is possible to work around once the existence of the error is known but I'm sure this isn't intended behaviour so I'm bringing it to your attention.
Thanks for a great library!
Firstly, the compiler warning is that the the method will run synchronously, implying it should be equivalent to the second method, and doesn't mention anything about not being in test mode.
Secondly, adding "await Task.Delay(100);" to the method doesn't change the test error but removes the warning.
Finally, as background, in the actual code that first produced the error, the setup method was part of an integration test class and had the [TestInitialize] attribute to run it automatically. It contained code to set up database client and secure storage classes which require async calls. The code above is the minimum to reproduce the error. The real tests produced strange 401 errors and after investigation I realised, embarrassingly, I had been repeatedly pinging the actual REST service with garbage username, password and api keys. The work-around is fairly obviously to create two setups, one async and one not and call them in each test. However, it took an hour or more to strip the original code down until I could isolate what was breaking it.
@Rippletank Thank you for reporting this, you're definitely on to something here.
In order for
referenced this issue
Nov 7, 2018
referenced this issue
Jan 21, 2019
I've confirmed that
In the mean time, the work-around is pretty simple: if you want a class-level HttpTest instance, instantiate it in the constructor or synchronous setup, not async setup.
I don't believe this is fixable. As proven here and explained here, a caller can set a value on
That's what's happening here. Flurl uses
The work-around is pretty simple: create the
I evaluated this work-around and concluded it's not applicable here. Any way you look at it, something would still need to set a value on