Upgrade
Last updated
Was this helpful?
Last updated
Was this helpful?
See the for a complete list of changes from VCR 1.x to 2.0. This file simply lists the most pertinent ones to upgrading.
Ruby 1.8.6 and 1.9.1 are no longer supported.
In VCR 1.x, your configuration block would be something like this:
This will continue to work in VCR 2.0 but will generate deprecation warnings. Instead, you should change this to:
The cassette format has changed between VCR 1.x and VCR 2.0. VCR 1.x cassettes cannot be used with VCR 2.0.
The easiest way to upgrade is to simply delete your cassettes and re-record all of them. VCR also provides a rake task that attempts to upgrade your 1.x cassettes to the new 2.0 format. To use it, add the following line to your Rakefile:
Then run rake vcr:migrate_cassettes DIR=path/to/your/cassettes/directory
to upgrade your cassettes. Note that this rake task may be unable to upgrade some cassettes that make extensive use of ERB. In addition, now that VCR 2.0 does less normalization then before, it may not be able to migrate the cassette perfectly. It's recommended that you delete and re-record your cassettes if you are able.
VCR 2.0 allows you to register custom request matchers:
You can also pass any callable (an object that responds to #call, such as a lambda) to the :match_requests_on
option:
In addition, a helper method is provided for generating a custom matcher that ignores one or more query parameters:
VCR 2.0 supports multiple serializers. :yaml
, :json
, :psych
and :syck
are supported out of the box, and it's easy to implement your own. Custom serializers must implement #file_extension
, #serialize
and #deserialize
:
VCR 2.0 has new request hooks, allowing you to inject custom logic before an HTTP request, after an HTTP request, or around an HTTP request:
You can now define what requests get ignored using a block. This gives you the flexibility to ignore a requets based on anything.
VCR can integrate directly with RSpec metadata:
VCR 1.x integrated with Faraday but required that you insert VCR::Middleware::Faraday
into your middleware stack and configure stub_with :faraday
. VCR 2 now takes care of inserting itself into the Faraday middleware stack if you configure hook_into :faraday
.
When VCR is unsure how to handle a request, the error message now contains suggestions for how you can configure VCR or your test so it can handle the request.
VCR 2.0 has a new configuration option that will turn on a logging mode so you can get more insight into what VCR is doing, for troubleshooting purposes:
In VCR 1.x, a single HTTP interaction could be played back multiple times. This was mostly due to how VCR was implemented using FakeWeb and WebMock, and was not really by design. It's more in keeping with the philosophy of VCR to record the entire sequence of HTTP interactions (including the duplicate requests). In VCR 2, each recorded HTTP interaction can only be played back once unless you use the new :allow_playback_repeats
option.
In VCR 1.x, request matching was delegated to the HTTP stubbing library (typically FakeWeb or WebMock). They contain some normalization logic that can treat some URIs that are different strings as equivalent. For example, WebMock ignores the ordering of query parameters:
Sometimes the request or response body of an HTTP interaction cannot be serialized and deserialized properly. Usually this is due to the body having invalid UTF-8 bytes. This new option configures VCR to base64 encode the body in order to preserve the bytes exactly. It can either be configured globally with a block, or set on individual cassettes:
VCR 2, the :uri
matcher simply . This means that there are some cases of non-deterministic URIs that VCR 1.x matched but VCR 2.0 will not match. If you need the :uri
matcher to be tolerant of slight variations like these, you can easily override it: