Is it correct to store vcr cassettes in repository?

Question

I develop a Ruby interface for one REST api. I use rspec and vcr for testing.
All tests use credentials of account, specially created for it.
I can't decide: is it correct to store cached responses of my tests(vcr cassettes) in repository, or allow users and subscribers to write their own cassettes?

By the name of the Emperor! Let the Holy War begins!

Answer 1

As long as you aren't including any sensitive information in the requests then I see no reason why you can't commit them.

But as long as it will work fine after first test seeding the cassettes there isn't too much at stake either way.

Personally I like the idea of being checked against historical requests in case I have to diagnose some obscure machine-specific error changing my request formats. (IE some encoding bug where things are being escaped incorrectly due to a dynamically loaded library).

Answer 2

VCR's cassettes play as the fixture of your tests. You do need to commit them into repository otherwise your tests won't run correctly in others' machine, or only correct there with heavy external dependency which is a violation of testing principle.

Of course you need to hide your credentials from public or team while keeping the above.

The solution is filter_senstive_data settings and Figaro gem.

At first, This answer from Myron in a similar question can solve your problem largely.

To setup VCR

VCR.configure do |c|
  c.filter_sensitive_data("<SOMESITE_PASSWORD>") do
    ENV['SOMESITE_PASSWORD']
  end
end

The above block of code copied from Myron's answer because I want to add more later

For more about this setting, check the doc https://relishapp.com/vcr/vcr/v/2-5-0/docs/configuration/filter-sensitive-data

Now, for ENV['SOMESITE_PASSWORD'], it can be real credential by using Figaro gem.

Installation of Figaro will create a file config/application.yml and add it to .gitignore. So, you can just input your credential username and password there without risking leaking it to public.