Undefined method `model_name' for NilClass:Class

Rails
21

Oh, don’t forget the :id in the call to edit

before(:each) do
@food = Food.new
@food.id = 1
end

describe “GET ‘edit’” do
it “should be successful” do
Food.stub(:find).with(“1”).and_return(@food)

  get :edit, :id => "1"

  assigns(:food).should == @food
end

end

Ken

22

Ya, that is not working. The code I gave you I was trying different
things
out.
Rails 3.0
Rspec rspec (2.6.0.rc6)

23

Dumb question, do you have required “spec_helper” at the top of the
file?

Ken

24

yes

25

The program works when I run it on the server.

describe FoodsController do
render_views

before(:each) do
Food.delete_all
login_as_admin
Food.stubs(:find).with(“1”).returns(@food = mock_model(Food,
:save=>false))
end

#describe “stub_model(Food) with a hash of stubs” do
#let(:food) do
# stub_model Food, :id => 5, :food =>{:name => ‘brisket’}
#end

 describe "GET edit" do
     it "should assign the requested food to @food" do
       #Food.should_receive(:find).with("1").and_return(@food)
       puts @food
       get :edit, :id => @food.id
       assigns(:food).should be(@food)
     end
   end

end

26

Can you give me the whole test code, with no comments? Just the stuff
you
are running.

Thanks

Ken

27

On 2011-05-31 1:57 PM, Chris H. wrote:

end
get :edit, :id => @food.id http://food.id
If this is how you are actually making the ‘get :edit’ call, you might
try converting your @food.id to a string. When the controller gets the
params, everything is a string, but if you give RSpec an integer, it
will obediently pass it along.

get :edit, :id => @food.id.to_s

I should point out at this point that I have not yet really used the
RSpec 2.x family, so I might be mistaken. But with 1.x, this is the
case.

Peace,
Phillip

28 
Food.stubs(:find).with("1").returns(@food = mock_model(Food,
      #Food.should_receive(:find).with("1").and_return(@food)

I should point out at this point that I have not yet really used the RSpec
2.x family, so I might be mistaken. But with 1.x, this is the case.

Peace,
Phillip

I want to point that the @food.id =1 is not really part of the test, but
is
to make “render_views” work. If @food is placed into a path, such as
edit_food_path(@food), the method will require that @food.id be set. By
setting it at the beginning of the test, you help Rails out.

As for the line that calls the controller action, it’s important to pass
a
string because this is what Rails would do. It will not convert it to an
integer. In fact, find(“1”) will still work in the real world - Rails
itself
will convert “1” to 1 internally. This is why you don’t have to say,
Food.find(params[:id].to_i)

While it might be a bit confusing, the “1” and the @food.id = 1 are not
related. Honestly, you can use id of 50 or whatever you wanted - it’s
just
best to make sure it’s not nil.

However, there is one exception to this rule. When you are testing the
controller’s new action, you SHOULD set @food.id = nil. Why? Because
you
want to test how the form_for in the _form.html.erb behaves given an
object
without an id. It needs to work properly given objects with and without
ids.
If you always set @food.id to some value, you won’t be testing the case
where _form.html.erb is given a new object - and this can spell
surprises in
some cases.

Ken