Multiple requests to the same URI/method return results as recorded

[jdoxey]

Hi Dustin,

First of all, thanks for creating VCRURLConnection! We've loved using VCR on ruby projects and were excited to find someone maintaining a objective-c version. We're using it for all of our acceptance tests on our new mobile app.

We noticed that multiple requests to the same URI/method would return the same result. This pull request is a fix that we're using from our forked version. We'd love to get your feedback on this approach and ultimately have this functionality contributed back into your version.

We're under the pump at the moment trying to get a release out, ideally we'd like to clean up and test the logic in recordingForRequestKey:key some more. We thought we'd reach out to you about the general approach first.

Thanks again, we look forward to your response.

[dstnbrkr]

Hi @jdoxey,

Thanks and excited to hear you're using it for acceptance testing! I'll take a look at this and get back to you asap. Thanks!

[jdoxey]

Hi @dstnbrkr, I've found a few issues with my commit. It looks like the status isn't being recorded properly, and the order is upside-down. I'm looking into these now.

[jdoxey]

I've added a new commit to this pull request that fixes these issues for us. Turns out my initial solution was never recording hits to multiple URLs, it only worked while replaying JSON files I'd hand crafted.

I had to add a new method [VCR startRecordingDuplicates] so it knows wether a duplicate URL should be recorded or replayed. (The name needs some work.)

The changes are starting to be quite significant. I'd love to get your input on the overall approach.

Cheers,
John

[dstnbrkr]

Excellent - thanks for putting this together. I'm just about to cut a release to add NSURLSession support - I'll take a look right after that.

[dstnbrkr]

Apologies for my slow response. I've given this some thought and I believe dynamic responses would be a better solution for a case like http://time.com/utc. If recordings supported variables and there was a way to pass values (or blocks that yield values) to the cassette - then VCR could interpolate those values at playback time.

So in the case of time.com/utc, there could be a block that yields [NSDate date] whose string gets replayed every time time.com/utc is replayed (rather than being limited to n recordings of a pre-set time).

Thanks for taking the time to think this through and identifying the need here - I do believe you are correct that VCRURLConnection needs a way to provide changing/dynamic responses to a single URI.

[jdoxey]

That might be a nice option, but I think it's important to be able to record and play back simply.

[dstnbrkr]

Rather than mixing start and enabling recording of duplicates, how about:

• (void)setRecordingDuplicates:(BOOL)recordDuplicates;
• (BOOL)isRecordingDuplicates;

setRecordingDuplicates can be called before or after [VCR start] and have the same effect.

[dstnbrkr]

Fair enough, your feature is a good idea - let's make it happen. I added a bunch of comments inline. I added NSURLSession support between your original pull request and now, so unfortunately there's a pretty big rebase needed for this PR. The good news is that the updates include some better infrastructure for tests so you won't need to roll your own NSURLConnectionDelegate. There's now a reusable test delegate. Thanks for contributing this - let me know how I can help.

[dstnbrkr]

/cc @kreeger for any further feedback

[kreeger]

This is cool. I'm gonna try it out now that you've got NSURLSession support, too!

[dstnbrkr]

closing this PR as inactive