[rspec-users] get to a different controller

Andrew Premdas apremdas at gmail.com
Thu Jan 7 05:20:06 EST 2010


2010/1/7 Phillip Koebbe <phillipkoebbe at gmail.com>

>
>
> 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? 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.
>
>
You are using your base controller like an Abstract Class. In classic OO you
can't test such classes because you can't instantiate them. Things are a
little different here in Rails, but the parallel holds because you can't
route this class.  The classic way to test an abstract class is to
instantiate a concrete class from it and test that. This is what you've
done, created a concrete test class with a route. The only problem is you
think the class is bogus, but its not, its just what you want, you can see
that by how easy it is to spec. Once you've specified how this class works
you should be able to share that specification using the techniques Wincent
has shown. Saying that your other classes should behave like this special
test class is perfectly fine.

All best

Andrew






> Peace,
> Phillip
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100107/aac0f79d/attachment.html>


More information about the rspec-users mailing list