run the request in controller test just once but have multiple tests having expectations. possible?

[krtschmr]

i wonder if it's possible to run the request only once and then have multiple expectations on it structured in multiple tests.

let's pretend one request creates 10 different things and we need 20 expectations here (stupid example, i know) and we don't want to have one single test but structure it more.
the alternative would be to have a request in every test but that slows down the pipeline a lot.

any possibility?

context "runs the request just once" do
    before(:all) do
      @document = create :document
      @request = get :show, params: {id: @document.id}
    end
    it "has expectation" do      
    end
    it "has more expectation" do      
    end
    it "has other expectations" do      
    end
    it "checks random stuff" do
    end
  end

if i run this, i get

@routes is nil: make sure you set it in your test's setup method.

one working way is, but is there another?

context "runs the request just once" do
    request = nil
    before(:each) do
      request ||= begin
        puts "run me only once buddy"
        @document = create :document
        get :show, params: {id: @document.id}
      end
    end
    it "has expectation" do
      expect(request).to have_http_status(302)
    end
    it "has more expectation" do
      expect(request).to have_http_status(302)
    end
    it "has other expectations" do
      expect(request).to have_http_status(302)
    end
    it "checks random stuff" do
      expect(request).to have_http_status(302)
    end
  end

[pirj]

If you are looking for a way to make several expectations and just make the request once, you will have to do this in the context of once example.

The rule to have just one expectation is kind of obsolete. It was misinterpreted from the beginning: it was meant to have one business expectation per example, not one expectation statement.
So having have_http_status(:redirect) and redirect_to('/sign_in') is ok.

Remember, the failures can be aggregated, so if the first expectation fails, the rest will still be checked, see https://relishapp.com/rspec/rspec-expectations/docs/aggregating-failures that by the way, has an example similar to your case.

You can also use Ruby to make the code DRY, e.g. extract expectations to methods:

    def expect_request_to_redirect
       expect(request).to have_http_status(302)
    end

    def expect_request_to_redirect_to_sign_in
       expect(request).to redirect_to('/sign_in')
    end

    it "is ok" do
      expect_request_to_redirect
      expect_request_to_redirect_to_sign_in
    end

or to extract the matcher part to methods:

    def redirect
      have_http_status(302)
    end

    def redirect_to_sign_in
      redirect_to('/sign_in')
    end

    it "is ok" do
      expect(request)
        .to redirect
        .and redirect_to_sign_in
    end

or just use plain matcher compounding (.and), see https://relishapp.com/rspec/rspec-expectations/v/3-9/docs/compound-expectations

We'd prefer to keep off doing potentially dangerous changes to rspec-rails itself to provide the ability to make requests from the example group scope given so many options exist.

If you have further questions, let's discuss on the mailing list http://rspec.info/help/, or feel free to ask around on StackOverflow.

[krtschmr]

thanks @pirj , appreciate your answer.

i wish rubocop-rspec wouldn't have a rule that limits by default expectations to 5.... :(
sometime people take it as the source of truth and roll with it, having the idea it's bad to have 8 expectations in one go. say you want to test the complex json return of a deep nested json object that shows selected 12 resources and their special children. yeah, that's maybe 20 expectations. nothing wrong with it, right?

[pirj]

Actually, if we're talking about the same cop, RSpec/MultipleExpectations, the default is 1. So 5 is probably coming from your project configuration.

The community RSpec style guide (https://rspec.rubystyle.guide/#expectation-per-example) says:

For examples two styles are considered acceptable. The first variant is separate example for each expectation, which comes with a cost of repeated context initialization. The second variant is multiple expectations per example with aggregate_failures tag set for a group or example. Use your best judgement in each case, and apply your strategy consistently.

Check rubocop/rspec-style-guide#47 and rubocop/rspec-style-guide#11 to find out why this change to the style guide was made.