Forum: RSpec Attempting to speed up my controller specs: using before all fails?

I have a simple controller test, containing a.o. the following code:

    context "POST :create" do
      before (:each) do
        post :create, :user_id => @user.id,
             :account => { .. some data ... }
      end
      it { response.status.should == 201 }
      it { response.location.should be_present }
    end

Now I thought of a very simple way to speed up this test, and to use a
`before(:all)` instead of a `before(:each)`. In that case the POST
would only be done once.

So i wrote:


    context "POST :create" do
      before (:all) do
        post :create, :user_id => @user.id,
             :account => { .. some data ... }
      end
      it { response.status.should == 201 }
      it { response.location.should be_present }
    end

But then I get the following errors:

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

Is this by design? Is there a way to circumvent it?

Nobody?

On 12 October 2011 12:09, nathanvda <nathanvda@gmail.com> wrote:

> >       it { response.status.should == 201 }
> >       before (:all) do
> >        @routes is nil: make sure you set it in your test's setup
> http://rubyforge.org/mailman/listinfo/rspec-users
>

I'm afraid I can't help with your specific situation, except to say I've
faced weird issues like this with "before(:all)" in the past, and have
generally tried to stay away from it these days.

Also, the largest amount of time is generally involved in actually 
loading
up rails itself. Can you confirm that there's a significant amount of 
time
taken to execute your controller action?

Srushti
http://c42.in

On Oct 12, 2011, at 2:09 PM, nathanvda wrote:

>>       it { response.status.should == 201 }
>>       before (:all) do
>>        @routes is nil: make sure you set it in your test's setup
>> method.
>>
>> Is this by design?

Yes. rspec-rails wraps the rails' testing framework which doesn't have a 
before(:all) concept in it, so all the data is reset before each 
example. Even if we wanted to support this in rspec-rails (which I 
don't) it would require changes to rails first.

>> Is there a way to circumvent it?

Not really. I'd just stick them in a single example:

describe "POST create" do
  it "responds with a 201 and a location" do
    post :create, :user_id => @user.id, :account => { .. some data ... }
    response.status.should eq(201)
    response.location.should be_present
  end
end

This violates the "one expectation per example" guideline, but a) that's 
just a guideline, and b) the real benefit of following the guideline is 
that it tends to limit you to one event per example (which is a GOOD 
thing). If that event has multiple outcomes to check, however, I see 
little benefit in this guideline.

HTH,
David

Yes it's by design, no you cannot circumvent it. What you can do is use 
mocks to avoid expensive DB hits, or have multiple expectations in a 
single example.

Pat

p.s. This is Ruby, so you absolutely *can* circumvent it. How to do that 
and whether it's worth the trouble is up to you to figure out.