You might want to look into using a null object, and breaking that first spec up into several examples (a null object returns itself when sent a message it doesn't know how to handle)
http://gist.github.com/78570 I've built more than a few named_scope chains using this pattern, and it seems to work out okay. This approach is somewhat less brittle, in that it's not going to explode horribly if you change the order of the chain in the main method (if something else reads better, say) ... Downside is that it _won't_ catch if you add new methods to the chain. If that's a concern, you could complicate the setup a bit, to narrow the focus to _just_ the methods you want. @new_search = mock(Twitter::Search) new_search.stub!(:containing => new_search, :since => new_search, :not_retweeted => new_search, :fetch => new_search) On Fri, Mar 13, 2009 at 10:04 AM, Levy Carneiro Jr. <l...@levycarneiro.com>wrote: > Hello! > > I'm trying to spec a method, that has several chained calls. > > http://gist.github.com/78562 (spec) > http://gist.github.com/78563 (model) > > In the first spec, I'm trying to focus on the method calls that have to be > made, and the arguments they should receive. > > Is there a better way to spec the behaviour for these chained calls? It > just seems too many lines to me :) > > > Thanks a lot! > Levy > PS: I'm using my branch of the twitter gem, at > http://github.com/levycarneiro/twitter, which just adds this method > 'not_retweeted'. > > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- // anything worth taking seriously is worth making fun of // http://blog.devcaffeine.com/
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
