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

Testing RSpec
1

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?

2

Nobody?

3

On 12 October 2011 12:09, nathanvda [email protected] 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

4

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.

5

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