On Jul 10, 2011, at 8:03 AM, Jatin kumar wrote: > On Sun, Jul 10, 2011 at 4:30 PM, David Chelimsky <dchelim...@gmail.com> wrote: > > On Jul 8, 2011, at 5:37 PM, Dean wrote: > >> I'm getting the following RSpec failed test output when I run spec >> spec/controllers/macroposts_controller_spec.rb: >> >> http://pastie.org/2184821 >> >> Here's the controller code for the "create" action for which the tests are >> failing: >> >> http://pastie.org/2184834 >> >> And here's the relevant section of the macroposts_controller_spec.rb file: >> >> http://pastie.org/2184846 >> >> Finally, here are the factory definitions referenced in the _spec.rb file >> given above: >> >> http://pastie.org/2184863 >> >> Focusing on failures #1 and #2, it's clear enough from the error messages >> that in the "POST create success" path through the specs, the @macropost >> object isn't receiving :save. The site has no problem saving macroposts, but >> when I run the tests, the "if @macropost.save" line in the controller seems >> to never get executed, or the save process is failing silently, perhaps due >> to validation problems. >> >> When I try to walk through the process in the console (in the "test" >> environment) I'm able to produce a valid @macropost object that saves. Yet >> for some reason, my test specs cannot. >> >> Any suggestions? Obvious things I've missed? Additional info I can provide? > > Hi David, > > The Project returned by "@project = Project.find(params[:project_id])" in the > controller action is not the same object as the one defined in the spec. This > is going to change in rails-3.1 (if you configure it to use the new > identiy_map feature), > > I had the same problem as above, and I used the same solution as you > said.i.e. replacing should_receive with stub. However, I never got to > understand why it worked. > > As you said, the objects returned in the spec are different but that is going > to change in rails-3.1. > Can you elaborate a bit on the details of the change. > > May be point me to a blog post written over it, and if there's not one now, > why not you write yourself one explaining the whole thing, when you find time.
Google "identity map in rails 3.1" There are a lot of posts about it. > BTW, I am a great fan of yours and your blog has helped a lot, learning the > basics of TDD by reading your articles and answers here & the rspec forum. > > but that is the case for all previous versions. > > To get the examples to work as written, you need to add: > > Project.stub(:find).and_return(@project) > > That should get these examples to pass, but there are a number of problems > with the overall approach. > > One reason to use stubs is to isolate yourself from the real models. That way > changes to validation rules, etc, don't cause your controller specs to fail, > and your specs run significantly faster as well. Since these examples use > real models, you're not getting the isolation benefit. > > Additionally, stubbing nested resources like this gets pretty complicated and > difficult to maintain. > > Lastly, the controller action violates "Skinny Controller, Fat Model" [1], > and that is complicating these specs quite a bit. > > With all that, I'd refactor the action to add the project and user IDs to the > macropost hash, just interact with that model only, and move the mailer logic > to an after_save hook on the model. The resulting controller and spec would > look something like https://gist.github.com/1074456. Note that there is only > one stub, and it is dead simple. > > The only thing keeping these examples slow now is the creation of a real > User, but you could probably stub that out as well. > > HTH, > David > > [1] http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model > > > >> Thanks! >> >> Dean Richardson
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
