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).wi
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 examp
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)
On Sat, May 28, 2011 at 8:12 AM, Jason Nah wrote:
> Guys,
>
> Just upgraded to rspec / rspec-rails 2.6 today and noticed that it pulled
> in rake 0.9.0 which was causing the rails 3.0.7 tasks to blowup.
>
> I've downgraded rake to 0.8.7. Are there any 'side-effects' that may impact
> the operatio
On May 28, 2011, at 7:12 AM, Jason Nah wrote:
> Guys,
>
> Just upgraded to rspec / rspec-rails 2.6 today and noticed that it pulled in
> rake 0.9.0 which was causing the rails 3.0.7 tasks to blowup.
RSpec doesn't have a runtime dependency on rake, so it was not RSpec that
caused this. It's mor
Guys,
Just upgraded to rspec / rspec-rails 2.6 today and noticed that it pulled in
rake 0.9.0 which was causing the rails 3.0.7 tasks to blowup.
I've downgraded rake to 0.8.7. Are there any 'side-effects' that may impact
the operation of rspec?
Cheers,
Jason
