Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add :single_cassette option to RSpec metadata #700

Closed
rachel-carvalho opened this issue Mar 21, 2018 · 7 comments · May be fixed by #761 or #836
Closed

Add :single_cassette option to RSpec metadata #700

rachel-carvalho opened this issue Mar 21, 2018 · 7 comments · May be fixed by #761 or #836

Comments

@rachel-carvalho
Copy link

Background

I've been testing an API call with VCR that I can't really re-do (it works a bit like a delete) because I have to create it manually and use the resulting id in my spec. It's something like this:

describe '#delete', :vcr do
  let(:foo) { API::Foo.new('ID that I can only get manually') }

  subject { foo.delete }

  it 'changes status' do
    expect { subject }.to change foo, :status
  end

  it 'does something else' do
    # ...
  end

  it 'does a third thing' do
    # ...
  end
end

In this situation, each of the it blocks records its own cassette. But I need a new id for each new request, so when I'm re-recording my cassettes, the first it passes and the subsequent ones fail.

I could just copy/paste the first cassette with matching names for the other blocks, but it doesn't feel right.

Then I found I could use the :cassette_name option which ensures all my its use the same cassette.

So I changed my specs:

describe '#delete' do
  let(:foo) { API::Foo.new('ID that I can only get manually') }

  subject { foo.delete }

  context 'success', vcr: { cassette_name: 'API_Foo/_delete/success' } do
    it 'changes status' do
      expect { subject }.to change foo, :status
    end

    # ...
  end

  context 'failure', vcr: { cassette_name: 'API_Foo/_delete/failure' } do
    # ...
  end
end

But now I'm manually writing the cassette names to keep the same naming scheme as the automatically generated cassettes.

Proposed solution

It would be really cool if we could specify we want a single cassette to be generated based on the block path, like this:

describe '#delete' do
  subject { foo.delete }

  context 'success', vcr: { single_cassette: true } do
    # ...
  end

  context 'failure', vcr: { single_cassette: true } do
    # ...
  end
end

Sorry for the long wall of text and code, I couldn't find a succinct way to explain this.

I'd love have a go at this if you guys think it's a good idea (although I'll be leaving on vacation soon and will probably not have access to a computer for at least a month, but I'll do it then).

I realize there might be something I'm not doing right here so I'm open to suggestions that don't include adding a new feature :)

@mcmire
Copy link

mcmire commented Jun 13, 2019

I just came across into this and I'm curious if I want a similar feature than you. Would single_cassette generate a cassette for the entire context as a whole instead of each test individually?

@dieggofaustino
Copy link

I'm with the same problem right now and found this by searching for a nice solution. In my case all it inside a context should use the same cassette

@ixti
Copy link

ixti commented Jun 19, 2019

This especially handy when you have bunch of it { is_expected.to ... } blocks.

@ixti
Copy link

ixti commented Jun 19, 2019

I would like to note though, that proposed API seems a bit confusing although all my attempts to propose something better failed.

@mcmire
Copy link

mcmire commented Jun 19, 2019

I agree about the API. I'm wondering if cassette_group or group_cassettes would be a better name:

describe '#delete' do
  subject { foo.delete }

  context 'success', vcr: { cassette_group: true } do
    # ...
  end

  context 'failure', vcr: { group_cassettes: true } do
    # ...
  end
end

@hirowatari
Copy link
Contributor

I absolutely love this feature and have been wanting it since I started using VCR at least 5 years ago. I'd like to help push this over the finish line if that's is desired still (if not just let me know).

I believe what is preventing the merge is:

  • the API name
  • tests are failing
  • documentation is missing

Is that true?

Regarding the API name, my opinion is that group_cassettes: true would be the best name. cassette_group sounds like it could require a name like cassette_name does, whereas group_cassettes sounds like a question. single_cassette is okay too, and unique_cassette might be slighter better, but group_cassettes seems best to me.

@mcmire
Copy link

mcmire commented Oct 2, 2020

@hirowatari A maintainer could weigh in better of course, but your assessment sounds right to me just from looking at this issue and the related PR.

@vcr vcr locked and limited conversation to collaborators Feb 28, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
6 participants