[rspec-users] should_receive stubs methods?

Jonathan Linowes jonathan at parkerhill.com
Thu Jun 21 10:25:50 EDT 2007


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



More information about the rspec-users mailing list