Provide diffs/potential matches for "Nock: No match for request <string>"

Context

Q: What are you trying to do and how would you want to do it differently? Is it something you currently you cannot do? Is this related to an issue/problem?

Nock is very useful, but is has a usability problem when it comes to requests coming in that do not match what has been nocked out. It is a difficult problem to diagnose, often involving comparing two blobs of text side by side.

I would like to implement something that provides more detail in failures, ideally containing an AssertionError that would have an actual and expected values so that a test runner can provide a diff that is more legible. Too many times has some attribute/header been missing an s, for example. A diff would make that very easy to see.

Alternatives

Q: Can you achieve the same result doing it in an alternative way? Is the alternative considerable?

I’m not sure how else I can do this other than extending nock, which is why I’m opening this request before I attempt to implement it. If nock has a method to return existing interceptors with details, I think it could be done outside of nock (in chai or some other assertion library), but so far as I can see, .pendingMocks() and .activeMocks() only return a limited amount of information (no headers/body, for example).

I don’t see any easy way of doing it, specifically because I think it would involve getting all of the other faked out hosts/paths/etc.

Has the feature been requested before?

Q: Please provide a link to the issue.

Not that I have been able to find. Mostly I found the feature that added the body of the request that could not be matched. ( #34 ?)

I also found a number of bugs that were opened because of the confusion that this fairly opaque error prompts ( #995 #1049 #1116 #1048 )

If the feature request is accepted, would you be willing to submit a PR?

Yes! I’m filing this to get some suggestions of how to implement and/or alternatives of how I could get access to the available interceptors.

Specifically, it feels like there are a few cases that I would need to handle:

• If there is only one interceptor, it should be very easy to provide an AssertionError with an actual/expected
• If there are multiple assertion errors, I would imagine I would need to either A) figure out how to sort them and choose the “closest” match (levenshtein of json blobs? kind of gross but might work.) Maybe narrowing it down by host or some subset of attributes, akin to https://github.com/nock/nock/blob/beta/lib/interceptor.js#L211 ?

If I couldn’t find a good way of doing the second one, maybe provide a list of the other interceptors that have been specified? I’m not sure how to do that without being too noisy.

Thank you for your time in reading this!

[elliotf]

Happy to hear that folks are positive about this. I started messing about a bit attempting to get some sort of normalized view of an interceptor vs a request, using a form of levenshtein to sort the available interceptors (though it looks like Jaro-Winkler might yield better results) – so far I’ve learned that I have a lot to learn, but it at least looks doable.

[gr2m]

we can start by collaborating on an RFC-kind of Markdown document, explaining the use cases and error message we would aim for to retrieve in these cases, then once we agree on that we can implement it backwards from there 😃 By that time we might be done with the coverage and refactoring, too.

We don’t have an RFC process yet, we could create a pull request with a throw-away file such as RFC-1413-error-messages.md and then discuss there