Unit Testing FhirClient

[Lewellync]

I've recently started working on tests for a new project, and a part of that is mocking FhirClient behavior. Now in the project I'm working on, a FhirClient is instantiated and used to make several calls as part of logic to acquire some information (for example, an encounter is used to gather charge items, which are then used to get practitioners).

I would like to write a unit test for the happy path of these methods, but I'm running into issues when mocking.

For example, in this method, the happy path involves 3 calls to the FhirClient.SearchAsync<> method with 3 different types. Because FhirClient does not have an interface, I cannot mock these calls. But I can mock an HttpClientHandler and send it into my FhirClient! However, now, I need to mock 3 separate SendAsync's within the HttpClientHandler, because each of those 3 calls is going to return something different. I don't know how FhirClient arranges my call from SearchAsync to SendAsync (I could find out by reading the source code, but that seems to go against testing third party libraries).

At the moment, I end up with something like this, which works because I'm guessing at the implementation of FhirClient.

_httpClientHandler.Protected()
.Setup<Task<HttpResponseMessage>>("SendAsync",
    ItExpr.Is<HttpRequestMessage>(x => x.RequestUri.AbsoluteUri.IndexOf("encounter",
                                           StringComparison.OrdinalIgnoreCase) >= 0),
    ItExpr.IsAny<CancellationToken>())
.ReturnsAsync(encounterResponse);

_httpClientHandler.Protected()
    .Setup<Task<HttpResponseMessage>>("SendAsync",
        ItExpr.Is<HttpRequestMessage>(x => x.RequestUri.AbsoluteUri.IndexOf("practitioner",
            StringComparison.OrdinalIgnoreCase) >= 0),
        ItExpr.IsAny<CancellationToken>())
    .ReturnsAsync(practitionerResponse);

_httpClientHandler.Protected()
    .Setup<Task<HttpResponseMessage>>("SendAsync",
        ItExpr.Is<HttpRequestMessage>(x => x.RequestUri.AbsoluteUri.IndexOf("chargeitem",
            StringComparison.OrdinalIgnoreCase) >= 0),
        ItExpr.IsAny<CancellationToken>())
    .ReturnsAsync(chargeItemResponse);

_fhirClient = new FhirClient("https://localhost/", null, _httpClientHandler.Object);

One could argue that this means that these methods need to be refactored, but I imagine there's a lot of legacy code out there that can't just change that, so I can only think of 3 options.

1. Guess / look at the underlying FhirClient code to determine how to map my mocked calls to the actual SendAsync calls (this seems bad, shouldn't need to understand FhirClient to mock it)
2. Create my own interface overtop of FhirClient and mock that (also bad, creating an interface just for mocking)
3. Refactor legacy code to make sure every single call to FhirClient is encapsulated in a method that can be separately mocked (this doesn't seem that different from 2)

Any thoughts or comments on this design decision would be appreciated, I am generally confused what is the right way to go about this, or even think about this problem.

[Kasdejong]

We also mock test the FhirClient. I suggest you take a look at FhirClientMockTests.cs and SubstituteBuilder.cs. Note that we switched to nSubstitute instead of Moq

[Lewellync]

In your test, it appears to me that you still need to know the URI that the underlying client call would produce to properly mock it, so we're at my point in 1. This is fine if was designed in such a way that that is assumed knowledge, but I want to clarify the point.

To mock FhirClient, a coder needs to look at underlying FhirClient code to determine how to map a mocked call (say, a SearchAsync), because they will need to know how FhirClient creates the URI. It is impossible to mock FhirClient without looking under the hood, and this is understood and intended.

If this statement seems benign, that's fine, but I'm not familiar with how libraries should or shouldn't be structured, and want to make sure I understand the point.

[mmsmits]

Yes that's correct. Our FhirClient is written very generically (ofcourse), and can only be mocked in your case if you look at the internal code of the FhirClient a little bit. This is intended and cannot be easily changes for libraries.
Mock is of course a special pattern, on which you always need to know a little bit how the mocked part behaves and especially how in this case the response should look like.

Looking at your code, you are on the right track in mocking our FhirClient for you use case. Good luck!