dstnbrkr / vcrurlconnection Goto Github PK

VCRURLConnection doesn’t properly record requests if they have the same method and same URL but different headers and/or body. This is obvious when looking at the source code since VCRRequestKey is based on the URI and method properties only.

An example where this behavior becomes problematic is when using the Range header. Say you first ask for range 0-123 then you ask for range 0-12345. The second request will never be recorded because it’s considered equal to the first one since it has the same URL and same method.

I plan to work on this issue but before I start I’d like to know what’s the status of #16 as these issues are slightly related.

Currently it's brought it via VCRURLConnection but it should use the pod

   pod 'NSData+Base64', '~> 1.0.0'

Otherwise you can get conflicts

Currently is "save = string, load = url"

Is this pod still active? If not is there something else that has taken it's place?

Ensure JSON keys always appear in consistent order

The API I'm writing tests for with VCR requires some URLs to contain a time-based string signature, that renders a different signature every x seconds. When using VCR to replay url connections with newer signatures, the recorded url does not match and the test will attempt a new, actual connection to the server. This makes a lot of the testing code useless.

http://somedomain.com/v1/some/path?sig=5b4971244ce968c77294aa436616333e

Is there a way in the current VCR to somehow have a recorded call match outgoing requests with a different signature, maybe by changing the "uri" attribute of the json to include wildcards of some sort?

If not, would you be interested in a PR that adds this feature to VCR?

P.S. I absolutely love your VCR pod by the way, great job!

Why [VCR stop] is missing from following sample?

[VCR start];

NSString *path = @"http://example.com/example";
NSURL *url = [NSURL URLWithString:path];
NSURLRequest *request = [NSURLRequest requestWithURL:url];

// use either NSURLSession or NSURLConnection
NSURLSessionDataTask *task = [[NSURLSession sharedSession] dataTaskWithRequest:request];
[task resume];

// NSURLSession makes a real network request and VCRURLConnection
// will record the request/response pair.

// once async request is complete or application is ready to exit:
[VCR save:@"/path/to/cassette.json"]; // copy the output file into your project

It there any possibility for https session recording? Currently I can see only http requests are recorded.

Hi,

I recorded a response and play it back and expected a network error.
Apparently it could come from here:

// FIXME: store details of NSError in VCRResponse and populate here

Any chance to have it fixed?

I read the code, and I'm pretty sure you're doing it right with pretty print but the results don't match what I expect. Which is lines & tabbing. Instead it's a one liner.

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?

Hello,

There are 2 warnings Xcode currently produces about these lines:

+ (NSArray *)alternateSelectors {
    return @[ NSStringFromSelector(@selector(initWithRequest_VCR_:delegate:)),
              NSStringFromSelector(@selector(initWithRequest_VCR_:delegate:startImmediately:)) ];
}

Undeclared selector 'initWithRequest_VCR_:delegate:'
Undeclared selector 'initWithRequest_VCR_:delegate:startImmediately:)'

There is a warning Xcode produces about this line:

static void VCRStoreOriginalImplentation(SEL selector);

Unused function 'VCRStoreOriginalImplentation'

Thanks!

There has been quite a few commits since the 0.2.0 release. Are there any plans for a 0.2.1/ 0.3.0 with the latest changes?

Hello,

It would be great if VCRURLConnection could reflect its recording state, something very simple like having class-level property isRecording/setRecording:(BOOL)recording. It should be set/unset in +[VCR start] and +[VCR stop] methods respectively.

I would use it for things like:

if ([VCR isRecording]) {
    [VCR save:cassettePath];
}

Let me know, what you think about it.

Thanks.

I was able to get things working just from the ease of using Cocoapods, but many users won't be as lucky. Also, the tutorial is very, very limited. It would be nice to have instructions for how to get this to work when used only within XCTest classes (which is kind of the point of the project). The example project does not include any tests written against the sample project. These tests would be great examples of how to use VCRURLConnection from a unit-test standpoint. I've been unable to find any outside tutorials online on how to use this successfully with Tests. I'm relatively new to testing, so I don't fully understand how everything works together and I'm sure many more users could benefit from this tool and better setup/tutorials. Thanks!