Hey, I''m using rspec and rails and have a spec that tests if a before_filter is executed, I also have a spec that tests if a method called by the filter is executed. It appears however that when I should_receive something, it is no longer actually called when I fire the http request. I''m not sure how, or where exactly I should manually fire the filter, either before or after the http request sounds wrong. An option to should_receive that passes on the invocation would be helpful yet I see nothing relevant in the documentation. Cheers Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070621/4b692882/attachment.html
On 6/21/07, Ian Leitch <port001 at gmail.com> wrote:> Hey, > > I''m using rspec and rails and have a spec that tests if a before_filter is > executed, I also have a spec that tests if a method called by the filter is > executed. It appears however that when I should_receive something, it is no > longer actually called when I fire the http request. I''m not sure how, or > where exactly I should manually fire the filter, either before or after the > http request sounds wrong. An option to should_receive that passes on the > invocation would be helpful yet I see nothing relevant in the documentation.Sorry Ian, but this is not supported, nor will it likely ever be supported in RSpec''s mocking framework because it encourages coupling concepts together in examples. Expressing the expectation that this method gets called should be separate from examples that deal with the results of actually calling the method. If that doesn''t make sense to you, please post the actual examples and code that you have and we can discuss them. Cheers, David> > Cheers > Ian > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
In the case where the filter sets a variable (e.g. @value) used in the controller action, you cannot mock the filter. You''re then forced to mock any methods the filter calls. To address this I''ve tried to add a method in my spec that aggregates the filter mocks and stubs. The problem here is if the filter calls a method, and then the action calls the same one, I have to put things like .twice in the stub (the "should" usage count does not increment), which breaks the modularity. (Did someone say "getting too intimate"? :) linoj On Jun 21, 2007, at 8:38 AM, David Chelimsky wrote:> On 6/21/07, Ian Leitch <port001 at gmail.com> wrote: >> Hey, >> >> I''m using rspec and rails and have a spec that tests if a >> before_filter is >> executed, I also have a spec that tests if a method called by the >> filter is >> executed. It appears however that when I should_receive something, >> it is no >> longer actually called when I fire the http request. I''m not sure >> how, or >> where exactly I should manually fire the filter, either before or >> after the >> http request sounds wrong. An option to should_receive that passes >> on the >> invocation would be helpful yet I see nothing relevant in the >> documentation. > > Sorry Ian, but this is not supported, nor will it likely ever be > supported in RSpec''s mocking framework because it encourages coupling > concepts together in examples. Expressing the expectation that this > method gets called should be separate from examples that deal with the > results of actually calling the method. If that doesn''t make sense to > you, please post the actual examples and code that you have and we can > discuss them. > > Cheers, > David > >> >> Cheers >> Ian >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On 6/21/07, Jonathan Linowes <jonathan at parkerhill.com> wrote:> In the case where the filter sets a variable (e.g. @value) used in > the controller action, you cannot mock the filter. You''re then forced > to mock any methods the filter calls. > > To address this I''ve tried to add a method in my spec that aggregates > the filter mocks and stubs. The problem here is if the filter calls a > method, and then the action calls the same one, I have to put things > like .twice in the stub (the "should" usage count does not > increment), which breaks the modularity. (Did someone say "getting > too intimate"? :)Use stubs! or should_receive(:blah).any_number_of_times.> > linoj > > > On Jun 21, 2007, at 8:38 AM, David Chelimsky wrote: > > > On 6/21/07, Ian Leitch <port001 at gmail.com> wrote: > >> Hey, > >> > >> I''m using rspec and rails and have a spec that tests if a > >> before_filter is > >> executed, I also have a spec that tests if a method called by the > >> filter is > >> executed. It appears however that when I should_receive something, > >> it is no > >> longer actually called when I fire the http request. I''m not sure > >> how, or > >> where exactly I should manually fire the filter, either before or > >> after the > >> http request sounds wrong. An option to should_receive that passes > >> on the > >> invocation would be helpful yet I see nothing relevant in the > >> documentation. > > > > Sorry Ian, but this is not supported, nor will it likely ever be > > supported in RSpec''s mocking framework because it encourages coupling > > concepts together in examples. Expressing the expectation that this > > method gets called should be separate from examples that deal with the > > results of actually calling the method. If that doesn''t make sense to > > you, please post the actual examples and code that you have and we can > > discuss them. > > > > Cheers, > > David > > > >> > >> Cheers > >> Ian > >> > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-users > >> > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
cool! On Jun 21, 2007, at 9:51 AM, David Chelimsky wrote:> On 6/21/07, Jonathan Linowes <jonathan at parkerhill.com> wrote: >> In the case where the filter sets a variable (e.g. @value) used in >> the controller action, you cannot mock the filter. You''re then forced >> to mock any methods the filter calls. >> >> To address this I''ve tried to add a method in my spec that aggregates >> the filter mocks and stubs. The problem here is if the filter calls a >> method, and then the action calls the same one, I have to put things >> like .twice in the stub (the "should" usage count does not >> increment), which breaks the modularity. (Did someone say "getting >> too intimate"? :) > > Use stubs! or should_receive(:blah).any_number_of_times. > >> >> linoj >> >> >> On Jun 21, 2007, at 8:38 AM, David Chelimsky wrote: >> >>> On 6/21/07, Ian Leitch <port001 at gmail.com> wrote: >>>> Hey, >>>> >>>> I''m using rspec and rails and have a spec that tests if a >>>> before_filter is >>>> executed, I also have a spec that tests if a method called by the >>>> filter is >>>> executed. It appears however that when I should_receive something, >>>> it is no >>>> longer actually called when I fire the http request. I''m not sure >>>> how, or >>>> where exactly I should manually fire the filter, either before or >>>> after the >>>> http request sounds wrong. An option to should_receive that passes >>>> on the >>>> invocation would be helpful yet I see nothing relevant in the >>>> documentation. >>> >>> Sorry Ian, but this is not supported, nor will it likely ever be >>> supported in RSpec''s mocking framework because it encourages >>> coupling >>> concepts together in examples. Expressing the expectation that this >>> method gets called should be separate from examples that deal >>> with the >>> results of actually calling the method. If that doesn''t make >>> sense to >>> you, please post the actual examples and code that you have and >>> we can >>> discuss them. >>> >>> Cheers, >>> David >>> >>>> >>>> Cheers >>>> Ian >>>> >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users