small medium large xlarge

Back to: All Forums  Take My Money
Head_shot_pragsmall
08 Apr 2017, 00:01
Noel Rappin (48 posts)

Which directory of the code were you running when this happened?

The only thing I can think of is that the RSpec title is used to determine which VCR cassette is used, and if one of the files in there is bad for some reason, the test might be bad, but if you change the name it would re-attempt to contact the servers to create another VCR cassette.

Does that sound like it might be a cause?

Noel

Generic-user-small
08 Apr 2017, 02:02
Rails Engineer (11 posts)

First, I deleted /home/rails/code/server_charge/01/spec/vcr_cassettes in your working project to successfully pass the test, which generated:

/home/rails/code/server_charge/01/spec/vcr_cassettes/StripeToken/calls_stripe_to_get_a_token.yml

Then, I overwrote this file containing the VCR output generated by the successful test run with the file from my non-working project containing the VCR output generated by the failed test run. Running the test again in your working project resulted in a test failure. As expected, Rspec utilized the VCR file to replay the HTTP traffic.

Then, I deleted the vcr_cassettes directory in my non-working project to remove the possibility of Rspec utilizing any VCR history.

However, running the test in my non-working project still generated the same failure. Then, I performed the following steps: 1) Overwrote the Gemfile in my non-working project with the Gemfile in your working project. 2) Deleted Gemfile.lock in my non-working project. 3) Executed bundle in my non-working project. 4) Executed rspec spec/models/stripe_token_spec.rb in my non-working project.

This generated a successful test run in my non-working project. Then, I overwrote the Gemfile in my non-working project (your Gemfile) with my original Gemfile, performed steps 2-4, and successfully passed the test. So, I was unable to determine the cause of the failure.

Generic-user-small
08 Apr 2017, 02:12
Rails Engineer (11 posts)

In retrospect, I should have preserved the old Gemfile.lock to diff against the current one residing in the version of my project that passed the test.

You must be logged in to comment