You also want to make sure that @food has an id of some kind, or Rails
complains. For the 'new' action, you want to set @food.id to nil to make
sure the form works for the new action.
You might not think this is important, but it is. If you decide to move this
controller into a namespace for example, you are introducing a potential
problem where the new or edit form doesn't work anymore. I have found it
less trouble to actually test it to make sure Rails doesn't throw some error
about trying to find a 'show' action when it's not supposed to.
Ken
On Sat, May 28, 2011 at 11:47 AM, Ken Egervari <ken.egerv...@gmail.com>wrote:
> I just found it bothersome to use stubs when testing rails controllers.
>
> A far easier way to do this is to define what @food is in a before(:each)
> block and then use it in your tests:
>
> describe "GET edit" do
> it "should assign the requested food to @food" do
> Food.should_receive(:find).with("1").and_return(@food)
>
> get :edit, :id => "1"
>
> assigns(:food).should be(@food)
> end
> end
>
> This is still very fast, and it has the added benefit that you can use
> "render_views" at the top of the spec to test your routes, erb code, etc. ->
> which is REALLY valuable.
>
> Ken
>
>
> On Fri, May 27, 2011 at 12:39 PM, Chris Habgood <chabg...@gmail.com>wrote:
>
>> Never seen the error above before, code:
>>
>> describe "edit action" do
>> it "edit action should render edit template" do
>> food = Food.create(:name=>'mooo') #
>> Food.any_instance.stubs(:valid?).returns(true)
>> get :edit, :id => food.id
>> response.should render_template(:edit)
>> end
>> end
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
