Comments and changes to this ticket

• 

  linoj September 26th, 2008 @ 04:11 AM

  i've updated the ticket with an even simpler example

  • bug.zip 3.4 KB
• 

  David Chelimsky September 26th, 2008 @ 02:44 PM

  • → State changed from “new” to “open”

  Hey linoj,

  Thanks for the failing example, but I can't really run it w/o a rails app :)

  Any chance you could patch in a failing example to the rspec-rails code examples?

• 

  linoj September 26th, 2008 @ 05:20 PM

  i'm going away for the weekend so wont have time now but i've attached the files in a rails app

  • bug_with_rails.zip 605.4 KB
• 

  David Chelimsky September 29th, 2008 @ 02:54 PM

  • → Tag changed from “mocks rspec_on_rails” to “bug mocks rails rspec_on_rails”

  Hey linoj,

  There are three examples in which you posed questions. I can answer the first 2 but haven't figured out the 3rd.

  
    it "should have mighty STUBBED" do
      # WHY DOESNT THIS WORK
      template.stub!(:cool).and_return("stubbed")
      do_it
      response.should have_text(/mighty STUBBED/)
    end
  
    it "should have might STUBBED using controller" do
      # INTERESTING, THIS DOES WORK
      template.controller.stub!(:cool).and_return("stubbed")
      do_it
      response.should have_text(/mighty STUBBED/)
    end
  

  The reason the 1st fails and the 2nd passes is that these methods, while exposed to the view, are actually delegated to and executed in the controller. So when the view calls mighty_cool, it calls mighty_cool on the controller, which then calls cool, also in the controller (not back in the view).

  
    it "should stub Normal helper when controller stubbed" do
      # WHY DOESNT THIS WORK
      template.controller.stub!(:cool).and_return("stubbed")
      template.should_receive(:normal_helper).and_return('Stubby helper')
      do_it
    end
  

  This one I have no idea about, so I'll leave this open until it's resolved.

• 

  David Chelimsky September 29th, 2008 @ 04:26 PM

  OK - I've found the bug. It's most complicated.

  When using partial mocks, i.e. adding mock behaviour to real objects, the object is given an instance variable named @mock_proxy, which keeps track of everything related to message expectations and stubs on that object.

  When the example says template.should_receive(:normal_helper).and_return('Stubby helper'), @mock_proxy is assigned on the template, the real #normal_helper method is renamed to #proxied_by_rspec__normal_helper, and a new #normal_helper is defined which interacts with @mock_proxy.

  In this example, both the controller and the template have a @mock_proxy. When rails copies instance variables from the controller to the view, it copies the controller's @mock_proxy over to the view, overwriting view's @mock_proxy. So when the view receives #normal_helper, which is the rspec implementation, it tries to interact with the @mock_proxy, but that mock_proxy has references to the controller, not the view, so when it asks questions about the #normal_helper method, it raises an error, since the controller doesn't know about it.

  EEEEEK.

  My opinion is that this is a rails bug - that if there is already an instance variable with a given name in the view, that the controller should not overwrite it with it's instance variable.

  I'm going to start down that path.

  In the mean time, I'll look into monkey patching rails from rspec to see if we can bandage this in the short term. Until this is resolved one way or the other, however, you simply can't set messsage expectations or stubs on both the controller and the template in the same example.