[rspec-users] Stopping example execution?

[Britt Mileshosky]

----------------------------------------
> From: mileshosky at hotmail.com
> To: rspec-users at rubyforge.org
> Date: Sat, 28 Jun 2008 17:50:19 -0700
> Subject: Re: [rspec-users] Stopping example execution?
> 
> 
> 
> ----------------------------------------
>> From: mailing_lists at railsnewbie.com
>> To: rspec-users at rubyforge.org
>> Date: Sat, 28 Jun 2008 20:32:26 -0400
>> Subject: Re: [rspec-users] Stopping example execution?
>> 
>> 
>> On Jun 28, 2008, at 8:27 PM, Britt Mileshosky wrote:
>> 
>>>
>>>
>>> ----------------------------------------
>>>> Date: Sat, 28 Jun 2008 18:24:17 -0500
>>>> From: philodespotos at gmail.com
>>>> To: rspec-users at rubyforge.org
>>>> Subject: Re: [rspec-users] Stopping example execution?
>>>>
>>>> On Sat, Jun 28, 2008 at 5:57 PM, Britt Mileshosky
>>>> wrote:
>>>>>
>>>>> Hello, I'm wondering If I am missing something here when creating  
>>>>> an example that sets an expecation at the top or beginning of an  
>>>>> action but requires you to stub / mock everything that follows.
>>>>>
>>>>> Example:
>>>>> I want to test that a certain controller is running a  
>>>>> before_filter...thats easy:
>>>>>
>>>>> - controller.should_receive(:require_user)
>>>>> - do_get
>>>>>
>>>>> But now i've got to mock / stub everything else that comes behind  
>>>>> this filter so that I don't receive 'unexpected method' errors, or  
>>>>> other blowups because I am requesting the whole action.  Is there  
>>>>> anyway to stop execution after an expectation has been met? It  
>>>>> seems to me that this might clean things up a bit.  Not sure, I'm  
>>>>> still fairly new to BDD/Mocking by about 2 weeks.
>>>>
>>>> Yep, you can stub out the requested action on the controller. Say
>>>> you're testing that the :index action requires authentication:
>>>>
>>>>  controller.should_not_receive(:index)
>>>>  stub_not_logged_in
>>>>  do_get
>>>>
>>>> Or the opposite:
>>>>
>>>>  controller.should_receive(:index)
>>>>  stub_logged_in
>>>>  do_get
>>>>
>>>> Personally I prefer expecting the action instead of expecting the
>>>> filters, but I think both would accomplish the same goal, as long as
>>>> you tested the filter on its own. If you just wanted to stub out the
>>>> action to prevent it from doing anything, you could of course just  
>>>> use
>>>> controller.stub!(:index).
>>>>
>>>> HTH
>>>>
>>>> k
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>>
>>> So i did something like.
>>>
>>> - controller.should_receive(:before_filter_action)
>>> - controller.stub!(:action_after_filter)
>>> - do_get
>>>
>>> Works nicely... but if you think about it and look closely, we are  
>>> still stubbing methods after the intended expectation was met.  This  
>>> method just happens to encapsulate a whole other set of methods,  
>>> which is why it works nicely.
>>>
>>> But lets say i have something like this
>>>
>>> ---------------------------------------------------------------------------------------------------
>>>
>>> def some_action
>>>    @user = self.current_user
>>>    @account = self.current_account if self.has_account?
>>>    @person = @account.people.find(params[:person])
>>> end
>>>
>>> ---------------------------------------------------------------------------------------------------
>>>
>>> describe "with a logged in user"
>>>
>>>  before(:each) do
>>>    controller.stub!(:current_account)
>>>    @account = stub_model(UserAccount)  # Shouldn't have to stub here?
>>>    @person = stub_model(User)              # Shouldn't have to stub  
>>> here?
>>>    @people = mock("list of people")         # Shouldn't have to stub  
>>> here?
>>>    @people.stub!(find)                             # Shouldn't have  
>>> to stub here?
>>>    @account.stub!(:people).and_return(@people)           # Shouldn't  
>>> have to stub here?
>>>  end
>> 
>> 
>> 
>> Are you looking for the :null_object => true flag?
>> 
>> Scott
>> 
> 
> Scott, I don't believe so, but can you see where that might work in the example given above? I've never used the null_object flag, and looking at the documentation, it seems as though I'd still need to declare all my mocks at the very beginning, rather than incrementally as I work down through my code and examples.
> 

I just noticed, Scott truncated my email so the full example I gave is not shown above, please refer to the previous messages for my full example.

_________________________________________________________________
Earn cashback on your purchases with Live Search - the search that pays you back!
http://search.live.com/cashback/?&pkw=form=MIJAAF/publ=HMTGL/crea=earncashback