[rspec-users] ControllerExampleGroup.bypass_rescue

David Chelimsky dchelimsky at gmail.com
Thu Aug 11 08:40:33 EDT 2011


On Aug 11, 2011, at 7:17 AM, Justin Ko wrote:

> On Aug 10, 2011, at 11:13 AM, Lenny Marks <lenny at aps.org> wrote:
> 
>> As best I can tell, bypass_rescue from rspec-rails-1 is no longer part of rspec-rails, '> 2'. I had been using it on occasion for things like:
>> 
>> describe CorrespondencesController do
>> ...
>> describe '#show' do
>>   it "should raise an AuthorizationError if current user is not the correspondent " do
>>   bypass_rescue
>>       ...
>>       expect { do_get }.to raise_error(AuthorizationError)
>> 
>> I know there are conflicting opinions on whether or not it's a good idea to directly check for exceptions this way, but I've always felt that this was appropriate for testing a controller action in isolation where the responsibility of the action under test was only to raise the error.
>> 
>> Anyway, I couldn't find any recent references to this (not even in the rspec-rails repo). Is there any way to do this in rspec-rails-2 or is the official consensus to check only on response codes, etc... ?
>> 
>> -lenny
> 
> If you are rescuing an exception, test what the rescue does. Purposely cause the exception, then check the rescue does what it's supposed to.


Justin - that specifies how the controller handles exceptions, but not when they get raised, which is the purpose of bypass_rescue. In Lenny's example, above, the GET results in an AuthorizationError, but if that gets rescued then you have to specify it in terms of what the rescue does, not how it got to the rescue handler. That's probably OK in most cases, but there are cases where you have more than one way to get to a rescue, and you want to specify the details of how it gets there.

Lenny, this was an oversight. Please submit an issue to http://github.com/rspec/rspec-rails/issues and we'll see about getting this reinstated. No guarantees since so much changed in Rails between v2 and v3, but if it's reasonable to add I think we should.

Cheers,
David



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110811/e14ef555/attachment.html>


More information about the rspec-users mailing list