Rspec redirect matcher

[Trek]

Apologies if this has come up before:

I'd like to submit a patch for a chained rspec matcher for redirect
responses (similar to should set_the_flash.to("")). E.g.:

it { should respond_with(:redirect).to('http://google.com') }
it { should respond_with(:redirect).to(:action => 'index') }


I didn't see an existing ticket or discussion about this, but there
are a lot of forks on github and I didn't want to duplicate effort.

-Trek

[Dan Croak]

Trek,

I don't know of a patch that's come across our proverbial desks. Seems
like a good patch, though. Go fot it!

Dan

--
Dan Croak
@Croaky

[Trek Glowacki]

Cool beans, thanks
http://github.com/thoughtbot/shoulda/issues/#issue/62

[Ryan McGeary]

1) Maybe Joe should chime in here, but I thought the reason Joe didn't convert should_redirect_to to an rspec matcher was because rspec already has a redirect_to matcher.

2) If there's a need for an rspec matcher, wouldn't it be more idiomatic (from a shoulda perspective) to convert should_redirect_to to a matcher?

Afterall:

  it { should redirect_to('http://google.com') }

has more brevity than:

  it { should respond_with(:redirect).to('http://google.com') }

-Ryan

[Trek Glowacki]

rspec does have a redirect matcher that works with hashes and strings.
The only syntax addition here is the ability to take a symbol as an
action name shortcut:

should redirect_to({:action => 'index'})

vs

should respond_with(:redirect).to(:index)

it makes the two examples equally brief.

As it stands now with rspec + shoulda

should redirect_to('http://www.google.com')
should respond_with(:redirect)

_is_ a verbose (and redundant) test. Testing a redirect to a specific
location implies that the response is a redirect. You have just as
valid coverage by omitting the second spec:

should redirect_to('http://www.google.com')

But, you lose out on the consistency of having all your response specs
use the same syntax and the sentence-like wording that differentiates
general redirect responses from specific redirects.

Shoulda seems to follow the pattern of using chained method calls to
describe specificity in expectations:

it { should assign_to(:user) }
it { should assign_to(:user).with(@user) }
it { should set_session(:user_id) }
it { should set_session(:user_id).to(@user.id) }


For brevity's sake you could do away with `set_the_flash.to`:

should set_the_flash(/created/)
should set_the_flash # no argument defaults value to rspec anything()

but I don't think that reads as nicely.