Forum: Ruby on Rails RSpec, controller testing, and routes.rb

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ff168162d53e22788d576582b3527e97?d=identicon&s=25 Bill Kocik (Guest)
on 2007-06-29 18:20
(Received via mailing list)
I didn't see any forums or lists for RSpec users, so I'm hoping there
are RSpec users on this list who may be able to help.

I have this in my routes.rb:

map.signup 'signup/:step',
    :controller => 'register',
    :action => 'signup',
    :step => 1

This test in the associated *.rspec file passes:

it "should assign @step to 1 on a get to 1" do
  get 'signup', :step => 1
  assigns[:step].should equal(1)
end

This one fails:

it "should assign @step to 1 on a get to /signup" do
  get 'signup'
  assigns[:step].should equal(1)
end

Even though that second test fails, when running under mongrel the
controller does the expected thing. If I GET /signup, the @step
variable (which is simply assigned the value of params[:step] by a
before_filter) is set to 1 appropriately. It seems that the default
:step set in the routes.rb works when running in a server, but not
during testing. I find this odd, since I am able to test my routes
with route_for, and they all pass. It seems that during testing, some
of what routes.rb specifies works, and some doesn't.

Is this to be expected, or have I managed to break something? It's
sort of hard for me to accept that I cannot test behavior of my
controller that relies on mappings in routes.rb, so I'm guessing I've
got something wrong somewhere.

--
Bill Kocik

http://bkocik.net
Ef0db53920b243d6758c2f6b1306df0d?d=identicon&s=25 Steve Ross (cwd)
on 2007-06-29 18:28
(Received via mailing list)
rspec-users@rubyforge.org

(cross-posting)

On Jun 29, 2007, at 9:20 AM, Bill Kocik wrote:

>
>   get 'signup'
> of what routes.rb specifies works, and some doesn't.
>
> >

Steve Ross
sross@calicowebdev.com
http://www.calicowebdev.com
This topic is locked and can not be replied to.