Added different serialization to different data types. JSON is now serialized in plain text, so that it's more readable. Other types fall back to base64 as before. Includes tests.

Unfortunately I have not been able to pinpoint the issue yet (I have taken a look at the changes from 1.2.0 to 1.3.0) but I can share that I have a branch where all my tests correctly find the relevant cassettes on version 1.2.0 (and Xcode 9), but with 1.3.0 (and Xcode 10) the tests crash as the cassettes can't be found.

Something about the diff between 1.2.0 and 1.3.0 is causing this change. Any ideas what may be the issue?

If we can't pinpoint the problem, then maybe we should deprecate 1.3.0 and release it as 2.0.0 instead since the changes are seemingly breaking behavior.

This PR restructures the repo's directories to enable Swift Package Manager.

It also adds a build job to the travis matrix that ensures swift build is working. Unfortunately, SPM does not enable including other resources (i.e. bundled content) like Xcode so therefore swift test fails as cassettes cannot be found. Once support for bundling other resources with swift build, then we should update the travis script to run swift test.

Lastly, this fixes the travis builds that were broken on master.

Addresses #67

This PR adds the possibility to ignore the parts of the url when comparing requests. I added ignoreURLComponents options to the Session. This is useful when you are using two environments, sandbox and production. And the request may have a different scheme, port or host.

See my comments on this commit https://github.com/venmo/DVR/commit/ecabe603c5b01bcb9f84ad8465e1a2f6d118fc75 which replaced print and abort with fatalError.

Made the problem when response is nil a bit more obvious (+ removed a forced unwrap, FTW!) I encountered this when https failed to validate a certificate - response was nil, which crashed on the force unwrap during the creation of Interaction. If this happens now, it should be a bit more obvy.

Fixes #74 & #69

This PR fixes a regression that caused the http status code and http headers to not be recorded in the case of non-200 responses. I've added a test to avoid future regressions.

Note: This PR depends on the changes in @soffes's Swift 3 branch (#60), once that's merged I'll rebase this on master.

This PR makes it possible to use DVR in projects that use Alamofire to do their networking. The Alamofire team got us most of the way towards supporting this (see https://github.com/Alamofire/Alamofire/pull/795) by allowing users to inject the URLSession and Alamofire.SessionDelegate used by a manager, but we still need to do some work on DVR's side to ensure it's calling the appropriate delegate methods and whatnot.

In a broader sense, this PR does the following:

• Gives every data task has a unique task identifier
• Ensures that the backing session's delegate receives the appropriate delegate callbacks
• Implements the currentRequest and originalRequest properties on the DVR session
• Makes the state property accurate enough to satisfy Alamofire

It might also be worth updating the docs to include some instructions on using DVR with Alamofire since there's some stuff about it that's non-obvious. I'd be happy to write those if there's interest around this PR.

I've been using this in a production app's tests for a couple of days now and it works fantastically.

Hi there, I'm using DVR, and so far I've managed successfully to create tests when api requests return success. But now I want to test the failure of the same requests. So I'm facing a problem when using DVR to test failures (401, 404 etc)..

When run for 2nd time (first time is to record the response), instead of failure callback, success callback is called with the error response inside of it. Any idea why?

Using Alamofire. Example code (creating and executing any request):

request.validate().responseJSON(completionHandler: {
    response in
    switch response.result {

         case .success(let JSON):
// This is what gets called instead of failure. Response code is 401 and the JSON contains error message.

              callback(true, JSON, nil)

         case .failure(let error):
              if let data = response.data, data.count > 0 {
                  let JSON = try! JSONSerialization.jsonObject(with: data, options: .allowFragments)
                  callback(false, JSON, error as NSError?)
              } else {
                  callback(false, nil, error as NSError?)
              }
     }
}).resume()

Seems to be a new issue in 0.2.0. I get either Invalid request. The request was not found in the cassette. or Something has gone horribly wrong. before Xcode hits a breakpoint and promptly crashes.

Both my Xcode's (7.1 and 7.2-beta.3) crash when I run a test that uses DVR where no cassette exists yet. Crash happens right after DVR records the request, logs the fact to console and then aborts to stop running - immediately after or maybe even at the time of the abort there's a crash.

Here's a snippet from the crash log:

Crashed Thread:        38  <DBGLLDBSessionThread (pid=2221)>  Dispatch queue: DVTInvalidationPreventionQueue

DVR is probably not at fault here, but has anyone experienced this and been able to fix or workaround the crash?

Right now, our README is fairly sparse. It might be good to pull out some examples from our tests cases and document how DVR can be used in those situations.

Adds support to integrate DVR with Alamofire. Fix: https://github.com/venmo/DVR/pull/41#issuecomment-171917800.

I made a little code snippet about it: https://coderwall.com/p/sd7i2g/my-alamofire-dvr-recipe-for-network-testing-in-swift

I'm writing an API wrapper as a library and just started using DVR in my tests, loving it! I'd really love my library staying compatible with Cocoapods, Carthage and Swift Package Manager. This world of three different package managers to support is really something in this ecosystem 😃. My dependencies are declared and integrated via Carthage, which works just fine. Cocoapods doesn't really need to know about DVR since that never runs my tests anyhow. Buuut I kinda still want to be able to run swift test... Is there any way to currently accomplish this? I don't think SPM supports private/dev/test dependencies, does it? Or would it make sense to include DVR as a normal dependency but only require it in test files? Not sure how Swift handles that...

Nevertheless, support for SPM here would be superb and much appreciated. If it makes sense of course. Thanks! 😊

I was thinking having startRecording/stopRecording in a test is weird since you only record once. Those methods are used for batch requests in one cassette. It would probably be best if these were renamed to beginBatch and finishBatch (or endBatch).

The options added so far allow a user to select what attributes a request should be matched on.

Request matching options include URL, Path, HTTPMethod and HTTPBody.

I have added one test but this really needs more, I will add more once I find some time.