On Aug 11, 2011, at 8:59 AM, Justin Ko wrote:
>
>
> On Thu, Aug 11, 2011 at 8:40 AM, David Chelimsky <dchelim...@gmail.com> wrote:
> On Aug 11, 2011, at 7:17 AM, Justin Ko wrote:
>
>> On Aug 10, 2011, at 11:13 AM, Lenny Marks <le...@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
This has been taken care of.
https://github.com/rspec/rspec-rails/issues/425
Thanks David.
-lenny
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
> "there are cases where you have more than one way to get to a rescue"
>
> Wouldn't you just mock/do-whatever to ensure the correct path to the rescue
> for the particular example?
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
