I’d like to write a spec to ensure that this doesn’t regress, but my
imagination is failing me as to how to do it.
Any ideas?
Yes: don’t use inheritance for implementations. The bug you describe is
arguably a violation of the Liskov Substitution Principle, ie the
derived class changed the functionality it inherited in a way that broke
the expected behaviour of all derived classes.
If you can write a spec (possibly shared examples) that defines the
contract you expect all controllers to follow - eg display an error
page in this situation - you can run that against all your controllers.
Checking that you call super doesn’t necessarily give you this
security.
If you want to post #rescue_action_in_public there might be another way,
depending on your code. I’m no Rails guru though.
BTW if this sounds like a rant, it is I am constantly stamping my
feet over the way controllers in Rails, Merb etc are implemented, as
they make writing specs extremely difficult.
Let me know if this is not clear as I’ve thrown the email together in a
hurry before going home for the night…
Just ran into a bug in a rails app where ApplicationController
overrides rescue_action_in_public leading to the error page not being
displayed.
The fix was to call super at the end of the method.
I’d like to write a spec to ensure that this doesn’t regress, but my
imagination is failing me as to how to do it.
Two thoughts, one not very helpful, the other hopefully more so.
My approach with this area has been to ignore the mechanics of error
catching in controllers, to steer clear of rescue_action_in_public in
apps - using rescue_from instead - and using a custom matcher to check
that particular controllers declare that they rescue particular errors.
To ensure that, in practice, the right stuff happens I use Cucumber to
check that in a 404 type situation the right stuff happens across the
whole stack.
I am constantly stamping my