jko170 at gmail.com
Wed Feb 22 21:15:56 UTC 2012
On Feb 22, 2012, at 9:00 AM, Matt Wynne wrote:
> On 22 Feb 2012, at 15:41, David Chelimsky wrote:
>> On Tue, Feb 21, 2012 at 2:48 PM, Mike Pack <mikepackdev at 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
>>> 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.
> ^ Yep, what he said ^
> Freelance programmer & coach
> Author, http://pragprog.com/book/hwcuc/the-cucumber-book
> Founder, http://www.relishapp.com/
> Twitter, https://twitter.com/mattwynne
> rspec-users mailing list
> rspec-users at rubyforge.org
Now that I think about it, the only time I use stub_chain is in Rails controllers, for scopes (which is also pretty rare). I'm 100% for extracting stub_chain into a gem, along with any_instance. We could call it "rspec-mocks-extensions" :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users