Verify calls to the registered end points have been called [discussion]

There are times where we are setting up a number of requests to match in a test and as part of using the tooling to write the functionality we want to know when the setup calls have not been called when they should have been. So it can be used in a “test first” type of a way to make sure the setup urls are called when the fix has been developed. The ability to throw exceptions when calls are made which aren’t configured is great, it’s the opposite side of that functionality as I want it to fail or at least check when they’re configured and not called.

Describe the solution you’d like Some sort of public API which allows for verifying the registered calls have been called as part of the request and/or a way to verify all the calls which have been registered have been called.

Initial thoughts would be similar to the Verify behaviour functionality on Moq - https://github.com/moq/moq4/blob/7848788b5968eb29056599db91f9e9b9d16f9ba9/src/Moq/Mock.cs#L255

Describe alternatives you’ve considered I was thinking you could create custom content predicates which when matched could keep track of the url and request. Then using the lookup functionality at the end of the processing you could manually check that all the entries had been called as expected. The downside of this it would be custom for each test and would have to be manually setup each time.

I was thinking maybe it could be based off the key creation routine and how the registrations are added to the mapping dictionary and then when they are called through the GetResponseAsync method it could be set as matched. Then could either pass in the builder instance for the request (so it could generate the key again) to check, or some other mechanism to verify that the call had been requested.

The other check that it would need to do would be the ability to use some sort of predicate to make sure the correct call had been requested. For example when the same url needs to be called multiple times with different payloads. So I was thinking it could interrogate the payload as well so you could match it in the same way that you can register predicates in ForContent to match on the content as well as the url etc.

Maybe add an override to the Register method to something like …

public HttpClientInterceptorOptions Register(HttpRequestInterceptionBuilder builder, out string registrationKey)

So on each registration you can get access to the key value which has been used so you can then request back in later but not overly a fan of this API change.

Thoughts

Just wanted to add this here in case there was an appetite to do something like this. I would be happy to contribute a PR if I could get some guidance on naming and approach to make sure it fitted with the plan for the library.

[drewburlingame]

We could really use this feature. Have there been any updates on it? Is there anything we could help with?

@WestDiscGolf can you share an example of your work around?

[martincostello]

Hey Adam - I’ll have more of a think about this ~tomorrow~ over the next week or so, but initial thoughts are:

1. I have nothing against the idea of a sort of Moq-esque Verify()/Verifiable() functionality being made available.
2. I don’t think we’d want to expose the internal matching keys implementation out to the public API surface as it would make it harder to change the internals in the future to support emerging future use cases we don’t know about yet.

Maybe it could be done in a way where the InterceptingHttpMessageHandler “told” the HttpClientInterceptorOptions that a particular request had been matched, and then it just did whatever internally to mark the fact it had been matched.

https://github.com/justeat/httpclient-interception/blob/f7b1a10a99e37caf12385e35f178681d526dfe60/src/HttpClientInterception/InterceptingHttpMessageHandler.cs#L57-L67

The downside to that, like you allude to, might be that this would run matching delegates a second time and break tests that are relying on the number of times they’re invoked (like an HTTP 429 test) or something like that.

In terms of current plans, there’s just a bug fix I need to come back to (#360) to investigate more, plus updating to the .NET 6 SDK next month, so I don’t think you’d be tripping over anything.