Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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 -

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.


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.

Issue Analytics

  • State:open
  • Created 2 years ago
  • Comments:8 (5 by maintainers)

github_iconTop GitHub Comments

drewburlingamecommented, Jul 6, 2023

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?

martincostellocommented, Oct 21, 2021

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.

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Is there a way to signal that an endpoint should be called ...
enpoint A can only be called if endpoint B has been called before at least once. After endpoint B has been called, endpoint...
Read more >
Mockito: How to verify a method was called only once with ...
The first verify checks the expected parametrized call and the second verify checks that there was only one call to add at all....
Read more >
Phishing Quiz | Federal Trade Commission
This email could be a phishing scam, where you get a message that looks like it's from someone you know, asking you urgently...
Read more >
Checking if auto attended calls were picked up
I'm using the Microsoft Graph API's direct routing calls endpoint to retrieve a list of inbound/outbound calls made by my organization. We have...
Read more >
Multiple Endpoints in Clinical Trials Guidance for Industry
Multiple Endpoints in. Clinical Trials. Guidance for Industry. DRAFT GUIDANCE. This guidance document is being distributed for comment purposes only.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found