Post/Get methods not available in a before(:all) context

[whithajess]

Trying to perform a get or a post Inside a before(:all) context:

context 'valid request' do
  before(:all) do
    get 'test'
  end
  it { expect(response).to be_ok }
  it { expect(response.body).to include("success='true'")
end

I get this error:

Failure/Error: get 'test'
     RuntimeError:
       @routes is nil: make sure you set it in your tests setup method.

Were as this will work in a before(:each) context (without the intended result)

context 'valid request' do
  before(:each) do
    get 'test'
  end
  it { expect(response).to be_ok }
  it { expect(response.body).to include("success='true'")
end

This was raised after a discussion over on the rspec mailing list if you want some context as to why you would use this.

[cupakromer]

Yes, the routes are not available until an example is created (i.e. run). This mirrors how ActionController::TestCase works. It also prevents you from hitting some other strange issues with the database as transactions are also not available in before(:context) blocks.

In a spec the response helper is a bit magical in that it starts off as nil but then will always ever just be the last response. This would not make sense with regard to a before(:context) as any spec which makes another request would change it.

As this is just Ruby, you could exploit a closure to achieve this:

context 'valid request' do
  cached_response = nil
  before(:each) do
    cached_response ||= get('test')
  end
  it { expect(cached_response).to be_ok }
  it { expect(cached_response.body).to include("success='true'")
end

This also makes things a little more explicit. However, be aware that if you are grabbing other things from the database, to compare with the cached response object that may not work as expected across each spec.

[JonRowe]

@cupakromer I asked @whithajess to open this, I think if we can't support this then we should explicitly disallow it, and return a more helpful error message....

[cupakromer]

@JonRowe sure, such a message would be related to #1208. Based on the discussion there, that PR likely needs to be closed and a new approach taken.

[whithajess]

I just tested out ActionController::TestCase and with this I can get my intended functionality.

require 'test_helper'

class TestformsControllerTest < ActionController::TestCase
  test "should get index" do
    get :index
    assert_response :success
    # I just tested for a redirect which I knew would fail because I am unfamiliar with Minitest
    assert_response :redirect
  end
end

in my controller:

class TestformsController < ApplicationController
  def index
    p 'Index hit'
  end
end

and the result (note the request is only made once):

# Running:

"Index hit"
F

Finished in 0.038109s, 26.2408 runs/s, 52.4815 assertions/s.

  1) Failure:
TestformsControllerTest#test_should_get_index [/home/ubuntu/rails_form_tester/test/controllers/testforms_controller_test.rb:7]:
Expected response to be a <redirect>, but was <200>

1 runs, 2 assertions, 1 failures, 0 errors, 0 skips

Is the problem in rpsec that it is both seen as the test and assertion? because Minitest seems to split there assertions and test.

[JonRowe]

So that's the equivalent of this...

require 'test_helper'

#class TestformsControllerTest < ActionController::TestCase
describe "TestformsController" do

  #test "should get index" do
  it "gets the index" do
    get :index
    # assert_response :success
    expect(last_response).to be_success
    # assert_response :redirect
    expect(last_response).to be_redirect
  end
end

[JonRowe]

So not at all equivalent to what you were trying to do before...

[JonRowe]

This is the mini test equivalent of what you were trying to do...

require 'test_helper'

class TestformsControllerTest < ActionController::TestCase
  @response = get :index

  # because I think this is how the assert_response works...
  def last_response
    @@response
  end

  test "should get index" do
    assert_response :success
  end

  test "should redirect" do
    assert_response :redirect
  end
end

[whithajess]

Sorry I should have been more clear here. The response from mini test is what I wanted from discussion over here (rspec mailing list). The problem being that in rspec if I put two expect's into an it that the failure response will be

Failure/Error: gets the index 

not

Failure/Error gets the index
  - expected last_response to be redirect

If you check out the discussion I state putting multiple expect into it seems like an option but that it would seem to go against getting good failure responses.

[whithajess]

I am going to close this here as this looks like what I was asking here is not possible or the way to go.

[myronmarston]

The problem being that in rspec if I put two expect's into an it that the failure response will be

Failure/Error: gets the index 

Are you saying that with RSpec, if you use multiple expectations in one example, you only get the name of the example and not the failure message from the first failing expectation?

If so, that would be a new bug we've never seen before, and something we should address...but I've never seen RSpec do that. The expectation failure message is always printed with the built-in formatters. (Some 3rd party formatters may choose to omit it).

[whithajess]

Ah sorry, I have done a horrible job of explaining myself to the point I have confused everyone including myself (from my lack of understanding).

You are correct Rspec will print the first failing expectation in an it this is something I did not realise somewhere along this process I have attempted this multiple expect in the it and either ran into a bug or did not properly read the failure and was expecting from this code:

it 'should be a valid response' do
 expect(response).to be_ok.and eq 'test code'
end

something like this:

Failure/Error: It should be a valid response and expect(response) to be ok and expect(response) to eq `test code'

which is completely wrong! the response is like this

TestformsController should be a valid response
Failure/Error: expect(response).to be_ok.and eq 'test code'
  expected: "test code"
   got:.......

Unfortunately my problem was non existent and my explanation took on a completely different problem.

I apologize for wasting your guys time @myronmarston @JonRowe @cupakromer