[rspec-users] get to a different controller

Wincent Colaiuta win at wincent.com
Wed Jan 6 16:45:37 EST 2010

El 06/01/2010, a las 16:17, Phillip Koebbe escribió:

> Wincent Colaiuta wrote:
>> I test inherited stuff with shared behaviors. It might be something  
>> you could use here.
>> Basically, I have a bunch of behavior in my ApplicationController,  
>> for example, and in my spec/controllers/ 
>> application_controller_spec.rb file I have a bunch of blocks like  
>> this:
>>  describe ApplicationController, 'protected methods', :shared =>  
>> true do
>>    ...
>>  end
>>  describe ApplicationController, 'parameter filtering', :shared =>  
>> true do
>>    ...
>>  end
>> And I then group them all together in one more shared behavior:
>>  describe ApplicationController, :shared => true do
>>    it_should_behave_like 'ApplicationController protected methods'
>>    it_should_behave_like 'ApplicationController parameter filtering'
>>    ...
>>  end
>> And finally in all subclasses which inherit I can now just do:
>>  describe ArticlesController do
>>    it_should_behave_like 'ApplicationController'
>>    ...
>>  end
>> So the behavior inherited from the superclass is specified, but it  
>> is also tested independently by the inheriting subclasses.
>> I imagine the same idea might be adaptable in some way for your use  
>> case.
>> Cheers,
>> Wincent
> Hi Wincent,
> Thanks for the input. I like the idea of the shared behavior so it  
> gets tested at all points of execution. [And I really enjoyed  
> David's "Yay!", too. :) ] I am going to keep that in mind as I go  
> forward. In this particular case, my dilemma was how to test the  
> behavior in the base_controller to begin with. The problem stemmed  
> from the fact that there were no actions in the controller to call  
> so I couldn't do a get on it. With Matt and David's help, I have  
> achieved what I was originally after.  The gist is updated if you  
> are interested:
> http://gist.github.com/269544
> I'm not sure how to share the behavior now, though. As I look at the  
> context that implements the testing of the before_filter, sharing it  
> doesn't seem to make sense since it creates a bogus derived class to  
> do the testing. If I share the behavior to real derived controllers,  
> it doesn't seem to me that they will, in fact, be tested.
> Do you have any thoughts on that?

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  

- 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  

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


More information about the rspec-users mailing list