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.
Peace,
Phillip
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
