[rspec-users] get to a different controller

Wincent Colaiuta win at wincent.com
Thu Jan 7 02:22:50 EST 2010


El 07/01/2010, a las 03:53, Phillip Koebbe escribió:

> Wincent Colaiuta wrote:
>>
>> Well, there is more than one way to skin a cat, but the thing I  
>> like about my proposed solution is that:
>>
>> - the specification of the behavior appears in the "describe" block  
>> that corresponds to the controller where the behavior is implemented
>>
>> - but given that the implementing controller is an abstract one,  
>> you actually test the behavior where it is actually exercised (ie.  
>> in the subclasses)
>>
>> - you don't need to make a fictional controller which isn't  
>> actually part of your application purely for testing purposes
>>
>> Looking at the gist you pasted it looks like it could be very  
>> straightforward to test, especially if you're using a RESTful  
>> access pattern.
>>
>> Your admin controllers all inherit from your abstract base class,  
>> and if they're RESTful you know before you even start which actions  
>> they'll respond to (the usual index, new, create etc). Perhaps they  
>> only respond to a subset; but even if they only respond to one  
>> ("show" or "index", say) you have enough of a common basis to test  
>> that the require_admin before filter is actually hit and does what  
>> you think it should (ie. you only need to hit "show" or "index",  
>> there is no need to test all actions).
>>
>> Cheers,
>> Wincent
>>
>
> Are you basically saying that you wouldn't worry about testing the  
> before_filter in the base_controller at all?

Exactly. The base_controller is never directly instantiated and its  
"behaviour" is only ever manifested in the context of its subclasses,  
so you can test the behavior by testing that it exists in the  
subclasses.

As you have seen, you can't really test the abstract base_controller  
directly itself because it has no actions.

> Maybe part of the reason I am not "getting this" is my lack of  
> familiarity with shared behaviors. If I share the behavior in the  
> base_controller_spec, will it get tested when I run that spec? If it  
> won't, then my concern is moot. If it will, then I'm just as  
> confused as I was before.

Shared behaviors are just a convenient way to define in behaviors once  
in a single place, which will be exercised in multiple places, so that  
you can keep things DRY.

If you run the file with the "describe foo :shared => true" block in  
it, nothing will actually happen.

Your assertions get exercised only when you run other "describe"  
blocks containing "it_should_behave_like ..."

They can be useful not just in cases like this where you have an  
abstract superclass. You can use them wherever you have a bunch of  
common behavior across different classes.

Cheers,
Wincent



More information about the rspec-users mailing list