VCRURLConnection can't handle testing multiple requests to the same endpoint

[Aaang]

Hi @dstnbrkr!

First of all, thanks for the great tool, it helps us a lot mocking the network communication and therefore speeding up our integration tests. Unfortunately we cannot use VCRURLConnection like it is for all our tests, because we've discovered a non-trivial issue:

Problem

We're dispatching multiple requests to the same endpoint with different response expectations within one test case, but VCR always overwrites the responses with the latest one.

Recording example:

1. verify that there are 0 issues: GET https://some.domain/issues - returns an array with 0 issues
2. create an issue: POST https://some.domain/issues - returns issue id 123
3. get all issues: GET https://some.domain/issues - returns an array with 1 issue
4. delete the issue: DELETE https://some.domain/issues/123
5. get all issues: GET https://some.domain/issues - returns an array with 0 issues

Replaying example:

1. verify that there are 0 issues: GET https://some.domain/issues - returns an array with 0 issues - luckily this succeeds
2. create an issue: POST https://some.domain/issues - returns issue id 123 - succeeds
3. get all issues: GET https://some.domain/issues - returns an array with 0 issues - FAILS
4. ...

We're getting the last recorded response for URL https://some.domain/issues every time in this test case.

Desired Behavior

Always get the correct response for the correct request, even when multiple requests to the same endpoint are dispatched.

Proposed Solution

To have a way to record and replay multiple requests to the same endpoint, i.e. instead of an array of VCRRecording objects, introduce a VCRRecordingSet holding a sorted array of VCRRecording objects as well as the main identifiers for the request (method and URL).

Matching the correct request could work similar to how it works right now with the only difference that we can't fetch the response from the VCRRecodingSetright away but would have to fetch it from the sorted array according to a certain index.

This would of course also mean that the VCRCassette or some other instance would need an additional state representing a request counter to read the VCRRecoding entries at the correct index from the sorted array.

Next Steps

I'll probably fork your implementation, if I find time and get the resources, to create a pull request with the suggested solution. But I'm not sure yet.

Have you thought about this issue already or did you specifically decide to go with the current solution for a special reason?

[dstnbrkr]

Thanks @Aaang - ordered recordings per url would be a great feature, does sound handy for mimicking state changes. Your solution sounds great - effectively mapping each request to a queue of responses and dequeueing per request during replay. I'd definitely welcome that pull request, thanks for proposing it!

[SoneeJohn]

@Aaan Awesome proposed solution, I noticed the same issue when using the Google API.