Detect unmatched body and match anyways

Context

We use nockBack and would like to improve cassette self-healing when the request signatures changes slightly. Ideally there would be a hook that allows us to:

1. Detect that no body is matched and
2. Force match the next recording in the cassette and replay that response (so further code can execute correctly).

We already have extensive self-healing capabilities of cassettes implemented, so this would allow us to extend / improve on that. The limitation of the self healing as implemented is that after the first recording is healed, the response is not replayed.

Alternatives

Currently we have to manually go through the cassettes and adjust the body to match the changes if there are requests depending on failed requests. This is feasible for small cassettes and we have been doing it for years now. However when a cassette contains thousands of requests this is no longer feasible and we need to re-record (which can be very hard when it requires complex state setup).

Has the feature been requested before?

AfaIk this feature has not been requested before.

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

Sure. As usually the biggest problem in this code base is figuring out where to make the change, so I’ll need help with that 😃

[simlu]

We’ve successfully implemented our change here using filteringRequestBody. We just assume that the request ordering in the recording is correct and hence do not need to know if “any interceptor matches the current request” (since we can just assume it’s the next available one).

Closing this since it seems to work fine.

@paulmelnikow Just a quick note on your comment that our “use case is kind of unusual”: We are using nockBack (which not a lot of people seem to use) and our requirements seem to be just a very natural evolution from using nockBack a lot. I would think that our use case would already be supported if more people were using nockBack.

I’m really not sure why nockBack isn’t more popular, since it makes all the manual setup in code unnecessary and the code becomes objectively much cleaner.

[simlu]

@paulmelnikow I’m giving a talk on test methodologies next week with focus on “testing the hard parts”. Recording and replaying external requests is going to be part of that. I’ll be writing some simple test cases using node-tdd and might post them here. It should make the value of node-tdd a lot clearer and hopefully help deciding on actionables for nockBack.

As you mentioned, I think a big part of why nockBack isn’t used more is documentation. The goal should be to have a clear and concise way to use nockBack and document that. Our wrapper node-tdd is fool-proof and allows “switching record-replay on” without requiring any additional knowledge beyond knowing what cassettes are and that they are automatically re-recorded when deleted.

I think more people would use nock if it was simpler to set up and not require any understanding of what requests are, how they are intercepted etc. So pushing nockBack forward would imo greatly help the popularity of nock if done correctly.

Does that all make sense to you? I really haven’t used nock much beyond what nockBack does. So am curious if you have a different take on this.