Make HttpCall Mockable

[rcollette]

Since there is no public constructor and HttpCall has no virtual implementation (no interface), it is not readily mocked, at least not without having to buy a framework to do so at an IL level.

 try
 {
    result = await _service.GetSomethingAsync(id);
 }
 catch (FlurlHttpException ex) when (ex.Call?.HttpStatus == HttpStatusCode.NotFound)
 {
    throw new NotFoundException($"Could not find with id {id}");
}

I can guess that there will be a response like "catch the exception where the call to Flurl is made and and throw your own exception". However, we then get into a non-DRY scenario or limiting access to the otherwise useful information in the FlurlHttpCall.

What would be the argument against exposing FlurthHttpCall's constructor and enough of the setup/setter functionality such that we can mock for unit tests accordingly?

[tmenier]

It has a public constructor. 3 actually. :)

[rcollette]

Sorry, my mistake. I should have said HttpCall. I have updated the issue accordingly.

[tmenier]

Ah, right you are. I agree, having a public constructor would make it more easily testable. I'm not sure off hand whether making one or both of the existing ones public would be most appropriate or whether creating a new one would be better (feel free to give me your preference), but I'll look into it for the next maintenance release.

[tmenier]

This is implemented and released in Flurl.Http 2.3.1.