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!
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
actualandexpectedvalues so that a test runner can provide a diff that is more legible. Too many times has some attribute/header been missing ans, 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 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!