[rspec-users] Stopping example execution?

[Britt Mileshosky]

----------------------------------------
> 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.


_________________________________________________________________
The i’m Talkathon starts 6/24/08.  For now, give amongst yourselves.
http://www.imtalkathon.com?source=TXT_EML_WLH_LearnMore_GiveAmongst