rspec users - May 2007 - Spec''ing redirect with arbitrary parameters

I''ve got the following expectation:

response.should redirect_to(:action => "new", :video_id =>
"1",
:process_id => "2", :origin_id => "3")

that fails with this error message:

expected redirect to {:video_id=>"1",
:process_id=>"2",
:origin_id=>"3", :action=>"new"}, got redirect to
"http://test.host/videos/1/screenshot_selections/new?process_id=2&origin_id=3",
which cannot be routed within this application (spec using the URL
string if the redirection is to an external address)

Seems like it doesn''t like the process_id and origin_id parameters.
Am I doing anything wrong or is it just a bug with the rails plugin?

Pat

On May 21, 2007, at 5:09 PM, Pat Maddox wrote:
> I''ve got the following expectation:
>
> response.should redirect_to(:action => "new", :video_id =>
"1",
> :process_id => "2", :origin_id => "3")
> that fails with this error message:
>
> expected redirect to {:video_id=>"1",
:process_id=>"2",
> :origin_id=>"3", :action=>"new"}, got redirect to
> "http://test.host/videos/1/screenshot_selections/new? 
> process_id=2&origin_id=3",
> which cannot be routed within this application (spec using the URL
> string if the redirection is to an external address)
You may need the controller name in the params.

It looks like you''re using resources.  If that''s the case, use
named
routes:

response.should redirect_to(resource_path(@video, @process, @origin))
> Seems like it doesn''t like the process_id and origin_id
parameters.
> Am I doing anything wrong or is it just a bug with the rails plugin?
My guess is that there is just some little nuance that is wrong.   
Does the url generate right in the browser?

Brandon

On 5/21/07, Brandon Keepers <bkeepers at gmail.com>
wrote:
>
> On May 21, 2007, at 5:09 PM, Pat Maddox wrote:
>
> > I''ve got the following expectation:
> >
> > response.should redirect_to(:action => "new", :video_id
=> "1",
> > :process_id => "2", :origin_id => "3")
>
> > that fails with this error message:
> >
> > expected redirect to {:video_id=>"1",
:process_id=>"2",
> > :origin_id=>"3", :action=>"new"}, got
redirect to
> > "http://test.host/videos/1/screenshot_selections/new?
> > process_id=2&origin_id=3",
> > which cannot be routed within this application (spec using the URL
> > string if the redirection is to an external address)
>
> You may need the controller name in the params.
>
> It looks like you''re using resources.  If that''s the
case, use named
> routes:
>
> response.should redirect_to(resource_path(@video, @process, @origin))
Cool, I changed it to
response.should redirect_to(new_screenshot_selection_path(:video_id =>
"1", :process_id => "2", :origin_id => "3"))

and it works fine now.  Thanks for the tip.

Pat

On 5/22/07, Pat Maddox <pergesu at gmail.com>
wrote:
> On 5/21/07, Brandon Keepers <bkeepers at gmail.com> wrote:
> > On May 21, 2007, at 5:09 PM, Pat Maddox wrote:
> > > I''ve got the following expectation:
> > >
> > > response.should redirect_to(:action => "new",
:video_id => "1",
> > > :process_id => "2", :origin_id => "3")
> >
> > > that fails with this error message:
> > >
> > > expected redirect to {:video_id=>"1",
:process_id=>"2",
> > > :origin_id=>"3", :action=>"new"}, got
redirect to
> > > "http://test.host/videos/1/screenshot_selections/new?
> > > process_id=2&origin_id=3",
> > > which cannot be routed within this application (spec using the
URL
> > > string if the redirection is to an external address)
Interesting.  I submitted the patch that changed around "should
redirect_to()" behavior a bit, and I confess, I haven''t had the
opportunity to use it much with named resources much yet.  That was to
get around an intermittent bug when the URL contained parameters on
the query string (but in a somewhat random order, so a simple string
comparison would intermittently fail).

The current behavior of the redirect_to matcher, when expecting a
hash, is to convert that hash into a URL and then *back* into a hash
(to pick up any magic dust that Rails might sprinkle in along the
way).  It also has to convert the response.redirect_url into a hash,
in order to do the comparison (and pick up any routing magic).  But
Rails doesn''t exactly make that easy for me.  ;-)

And it looks like my approach breaks with nested resources!  It seems
to work fine for the first level.  I was rather surprised to find that
the following will not work:

ActionController::Routing::Routes.recognize_path
"/videos/1/screenshot_selections/new"

So, I don''t have the time to look into it at the moment, but if
someone else knows how to get the correct hash from that URL path,
they could place that solution in line 48 of
vendor/plugins/rspec_on_rails/lib/spec/rails/matchers/redirect_to.rb.
> > It looks like you''re using resources.  If that''s the
case, use named
> > routes:
> >
> > response.should redirect_to(resource_path(@video, @process, @origin))
>
> Cool, I changed it to
> response.should redirect_to(new_screenshot_selection_path(:video_id =>
> "1", :process_id => "2", :origin_id =>
"3"))
>
> and it works fine now.  Thanks for the tip.
Yeah... if you are using resources, you should be using the named
route anyway.  ;-)  But I wonder if the unordered hash issue will
still cause occasional heartache...

new_screenshot_selection_path(:video_id => "1", :process_id =>
"2",
:origin_id => "3")
could theoretically generate both of the following:
"http://test.host/videos/1/screenshot_selections/new?process_id=2&origin_id=3"
"http://test.host/videos/1/screenshot_selections/new?origin_id=3&process_id=2"

Yuck!  Maybe the right solution is to enforce a strictly alphabetical
ordering within Rails itself?    Or should any URL which is routable
within the app be converted to a hash for comparison?

-- 
Nick

On 5/23/07, nicholas a. evans <nick at ekenosen.net>
wrote:
> On 5/22/07, Pat Maddox <pergesu at gmail.com> wrote:
> > On 5/21/07, Brandon Keepers <bkeepers at gmail.com> wrote:
> > > On May 21, 2007, at 5:09 PM, Pat Maddox wrote:
> > > > I''ve got the following expectation:
> > > >
> > > > response.should redirect_to(:action => "new",
:video_id => "1",
> > > > :process_id => "2", :origin_id =>
"3")
> > >
> > > > that fails with this error message:
> > > >
> > > > expected redirect to {:video_id=>"1",
:process_id=>"2",
> > > > :origin_id=>"3", :action=>"new"},
got redirect to
> > > > "http://test.host/videos/1/screenshot_selections/new?
> > > > process_id=2&origin_id=3",
> > > > which cannot be routed within this application (spec using
the URL
> > > > string if the redirection is to an external address)
>
> Interesting.  I submitted the patch that changed around "should
> redirect_to()" behavior a bit, and I confess, I haven''t had
the
> opportunity to use it much with named resources much yet.  That was to
> get around an intermittent bug when the URL contained parameters on
> the query string (but in a somewhat random order, so a simple string
> comparison would intermittently fail).
>
> The current behavior of the redirect_to matcher, when expecting a
> hash, is to convert that hash into a URL and then *back* into a hash
> (to pick up any magic dust that Rails might sprinkle in along the
> way).  It also has to convert the response.redirect_url into a hash,
> in order to do the comparison (and pick up any routing magic).  But
> Rails doesn''t exactly make that easy for me.  ;-)
>
> And it looks like my approach breaks with nested resources!  It seems
> to work fine for the first level.  I was rather surprised to find that
> the following will not work:
>
> ActionController::Routing::Routes.recognize_path
> "/videos/1/screenshot_selections/new"
>
> So, I don''t have the time to look into it at the moment, but if
> someone else knows how to get the correct hash from that URL path,
> they could place that solution in line 48 of
> vendor/plugins/rspec_on_rails/lib/spec/rails/matchers/redirect_to.rb.
>
> > > It looks like you''re using resources.  If
that''s the case, use named
> > > routes:
> > >
> > > response.should redirect_to(resource_path(@video, @process,
@origin))
> >
> > Cool, I changed it to
> > response.should redirect_to(new_screenshot_selection_path(:video_id
=>
> > "1", :process_id => "2", :origin_id =>
"3"))
> >
> > and it works fine now.  Thanks for the tip.
>
> Yeah... if you are using resources, you should be using the named
> route anyway.  ;-)  But I wonder if the unordered hash issue will
> still cause occasional heartache...
>
> new_screenshot_selection_path(:video_id => "1", :process_id
=> "2",
> :origin_id => "3")
> could theoretically generate both of the following:
>
"http://test.host/videos/1/screenshot_selections/new?process_id=2&origin_id=3"
>
"http://test.host/videos/1/screenshot_selections/new?origin_id=3&process_id=2"
>
> Yuck!  Maybe the right solution is to enforce a strictly alphabetical
> ordering within Rails itself?    Or should any URL which is routable
> within the app be converted to a hash for comparison?
Turns out the problem was that edge has moved parse_query_parameters
from CGIMethods to ActionController::AbstractRequest. This wasn''t
getting caught because the resulting error was being silently rescued.

Should have the fix committed shortly.
>
> --
> Nick
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>