On Tue, Feb 21, 2012 at 2:48 PM, Mike Pack <mikepack...@gmail.com> wrote: > Yup, I find myself doing this all the time. I think it should be considered > that too deep of a stub chain could be a sign of poor > abstraction/information hiding. Could lead to bad practices? On the > flipside, this would be super helpful when dealing with Railsy stubs because > of long scope chains (but IMO long scope chains should be enclosed in a > method). > > Also, why not rspec core?
First - it would be rspec-mocks, not rspec-core. Second - in all but the rarest cases (mostly fluent interfaces), it exacerbates highly coupled designs by making them seemingly easier to test (but in the long run they just add to the problems associated w/ coupling). This is already true of stub_chain, which I already regret including in rspec-mocks for these reasons. If @justinko introduces a separate gem for should_receive_chain, I'd probably want to move stub_chain to that gem as well. Note that I'm not saying that every use of stub_chain is incorrect, or un-pragmatic. I just think that if there's another way to get at that feature, rspec-mocks is better off without it. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users