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
>
>
>
>
> _______________________________________________
> 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
