Myron Marston's Profile

Comments by Myron Marston

It's a matter of tradeoffs and deciding what's important to you. I tend to check my VCR cassettes into source control, because I like having the history of what the HTTP responses were at a particular point in time. It allows me to git bisect through my history and having passing tests. If the cassettes are not committed to source control, and the HTTP responses have changed, you'll have a very hard time running the tests at an old commit.

However, committing the cassettes does tend to bloat your git repository with lots of extra files, and it makes it easy to wind up with tests that require particular exact cassettes (e.g. because you hand-edited them) to pass. I like that not committing cassettes encourages you to just treat them as a cache.

It's up to you ultimately -- just consider what is more important to you of the pros/cons I've listed here.

To add to what Ryan said...it depends on what you mean. If you want to use VCR to record/replay HTTP requests made by your rack application, and you are using capybara + selenium to do full-stack integration testing--then yes. VCR isn't coupled to a particular capybara driver (or any testing library, really) so it should work fine, as long as you are making HTTP requests with one of the supported HTTP client libraries.

If you are wanting to use capybara + selenium to test-drive an external website like what Ryan demonstrated with capybara-mechanize...then I'm not sure. I wasn't aware capybara-mechanize allowed you to do that.

Basically, VCR will work with anything as long as you are using one of the supported HTTP client libraries (or a library built on top of one of those--like how rest-client is built on top of Net::HTTP), you have control of the ruby process where the HTTP requests are being made, and you have a way to wrap the code making the HTTP requests in a VCR.use_cassette call.