Support multiple requests for the same url

[haitaoli]

Summary

This PR addresses issue #33.

• Recordings are now saved in an array for each url+method key.
• After a recording is replayed, it's removed from array. The last recording in the array is not removed, to maintain compatibility with current behavior.

If VCR is in both recording and replaying mode, the replayed recording is added back to the queue. This behavior doesn't make a difference when there is only one recording per url. But when there are multiple responses, this creates a "loop". For example, responses A and B are in the array, the replay sequence becomes A, B, A, B etc. If VCR is only in replay mode, then the replayed sequence is A, B, B, B...

[dstnbrkr]

Thanks @haitaoli, this looks interesting! I will review and get back to you.

[dstnbrkr]

The replaying:(BOOL) parameter makes the logic a little complex. What if instead there was no replaying parameter? Looks like that would be possible if recordingForRequestKey: used an index instead of mutating the recordings array. For instance, recordingForRequestKey could just increment an index and use index++ % [recordings count] to cycle through each recording for each request. Might make the test cases simpler too since you won't need to account for different behaviors depending on replaying/recording.

[dstnbrkr]

I don't see recordings getting mutated in a block, so this won't need the __block declaration.

[haitaoli]

recordingForRequest is called at two places, one to check if there is recording available (canInit), the other to get recording, so it cannot always increment the index. I thought about giving them different and more meaningful names such as hasRecording and replay, but that would require a lot of changes to rename it everywhere. If you don't mind a much bigger PR I can do that.

Cycling through all recordings might not be the ideal behavior. If replay runs out of recordings then something is wrong. In that case the latest response probably makes more sense.

[dstnbrkr]

Got it - given that it's used for both recording and replaying, what you have makes sense! So then the only outstanding item is the extra __block declaration and this is good to go. Thanks again for this contribution!

[haitaoli]

Removed uncessary __block.

[haitaoli]

@dstnbrkr thanks for merging it. Do you have plan to release a new version?

[dstnbrkr]

@haitaoli all set! (just shipped 0.2.3)

[haitaoli]

Great! Thank you.