Do you often find yourself doing this:
active = double(''active'')
active.should_receive(:first)
users = double(''users'', active: active)
account.should_receive(:users).and_return(users)
for this:
account.users.active.first
?
Of course, we could use stub_chain, but that doesn''t let us know
*where* the chain broke.
Would you like to do this?
account.should_receive_chain(:users, :active, :first)
Under the hood, it would create something like this:
users = double(''user'')
active = double(''active'')
first = double(''first'')
users.should_receive(:active).and_return(active)
active.should_receive(:first).and_return(first)
Note, this would *not* be part of RSpec, but rather a separate gem.
Would this alleviate any pain for you?
Hi Justin, On Tue, Feb 21, 2012 at 4:03 AM, Justin Ko <jko170 at gmail.com> wrote:> Would you like to do this? > > account.should_receive_chain(:users, :active, :first) > >I would love this syntax. I find that I usually resort to stub_chain and lose the ability to check that the object received a particular message.> Note, this would *not* be part of RSpec, but rather a separate gem. > > Would this alleviate any pain for you? >Why can''t it be a part of RSpec? Regardless, it would be a nice addition to my specs. Regards, Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120221/04cfb43e/attachment.html>
+1 I''ve often wondered if there is a better way to stub this situation. On Tue, Feb 21, 2012 at 7:43 AM, Ken Chien <ken.chien at gmail.com> wrote:> Hi Justin, > > On Tue, Feb 21, 2012 at 4:03 AM, Justin Ko <jko170 at gmail.com> wrote: > >> Would you like to do this? >> >> account.should_receive_chain(:users, :active, :first) >> >> > I would love this syntax. I find that I usually resort to stub_chain and > lose the ability to check that the object received a particular message. > > > >> Note, this would *not* be part of RSpec, but rather a separate gem. >> >> Would this alleviate any pain for you? >> > > Why can''t it be a part of RSpec? Regardless, it would be a nice addition > to my specs. > > Regards, > Ken > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- Tim Gremore 920 471-1716 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120221/a0ff4cf9/attachment.html>
> Would you like to do this? > > account.should_receive_chain(:users, :active, :first)+1 from me! Patrick J. Collins http://collinatorstudios.com
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? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120221/3a60b40a/attachment.html>
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 > 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.
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 >> 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.^ Yep, what he said ^ cheers, Matt -- Freelance programmer & coach Author, http://pragprog.com/book/hwcuc/the-cucumber-book Founder, http://www.relishapp.com/ Twitter, https://twitter.com/mattwynne -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120222/e2768593/attachment-0001.html>
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 >>> 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. > > ^ Yep, what he said ^ > > cheers, > Matt > > -- > 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 > http://rubyforge.org/mailman/listinfo/rspec-usersNow 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... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120222/f9d50125/attachment.html>
Hi all On Wednesday, February 22, 2012 9:15:56 PM UTC, Justin Ko wrote:> > > 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 > > 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. > > > ^ Yep, what he said ^ > > cheers, > Matt > > -- > 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 > http://rubyforge.org/mailman/listinfo/rspec-users > > > 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" :) >Came to this thread as I''m curious about how folk test data collection in their controllers. I feel I just want to just test message expectations as simple controllers are pretty dumb right? I certainly don''t wanna implement my own query interface (wrapping all scopes in methods) to enable setting message expectations and it seems we can stub (scope) chains but not set expectations. Just doesn''t quite feel right all of this.. Are you all really doing the kinda thing Justin suggests at the start of this discussion? Best. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120508/eef4ebbc/attachment.html>