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