[rspec-users] [rails] url_for host and protocol not set when full spec suite run
rockrep at yahoo.com
Thu Sep 16 02:44:15 EDT 2010
From: David Chelimsky <dchelimsky at gmail.com>
To: rspec-users <rspec-users at rubyforge.org>
Sent: Wed, September 15, 2010 8:51:48 PM
Subject: Re: [rspec-users] [rails] url_for host and protocol not set when full
spec suite run
On Sep 15, 2010, at 1:05 PM, Michael Kintzer wrote:
>RUBYGEMS VERSION: 1.3.7
>RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10.4.0]
>I'm getting different results when running a Rails 3 scaffold generated
>controller example depending on whether or not I run 'rspec spec' or 'rspec
>spec/controllers'. The difference occurs when evaluating the dynamic route
>methods with for '_url', e.g. my_model_url I'm using Authlogic and
>SslRequirement as well. The issue may be in either of those libraries, but the
>only difference is how I run the spec suite. I disable the Ssl requirement
>check in the test.rb environment file.
>Assume I generated the scaffold code with: "rails g scaffold scaffold" to
>create a "Scaffold" model.
>See relevant code here: http://gist.github.com/581130
>When I run 'rspec spec/controllers', the example in question passes. I placed
>debug code in url_for.rb (bartt-ssl_requirement-1.2.3) to parse the options
>passed to url_for and they include the :host and :protocol parameters, :host =>
>"test.host", :protocol => "http://".
>When I run 'rspec spec', the example in question fails. The url_for options
>are missing both the :host and :protocol parameters. If I manully pass those
>into the my_model_url method, the example will pass. If I use the _path
>version of the route method, the example passes.
>The stack trace in the failing case is (path to gems directory omitted):
>1) ScaffoldsController POST create with valid params redirects to the created
> Failure/Error: response.should redirect_to(scaffold_url(mock_scaffold))
> Missing host to link to! Please provide :host parameter or set
> # .../actionpack-3.0.0/lib/action_dispatch/routing/route_set.rb:473:in
> # .../bartt-ssl_requirement-1.2.3/lib/url_for.rb:44:in
> # .../gems/bartt-ssl_requirement-1.2.3/lib/url_for.rb:32:in `url_for'
> # .../actionpack-3.0.0/lib/action_dispatch/routing/url_for.rb:132:in
> # .../actionpack-3.0.0/lib/action_dispatch/routing/route_set.rb:195:in
> # ./spec/controllers/scaffolds_controller_spec.rb:70
> # .../activesupport-3.0.0/lib/active_support/dependencies.rb:239:in
>So, I'm stumped as to why 'rspec spec' is behaving differently from 'rspec
>spec/controllers' with respect to generating the appropriate url_for options.
This sort of problem usually boils down to something interacting with global
state - something that is only getting loaded when you run the full suite. To
narrow it down, try running subsets of the directories:
rspec spec/controllers spec/requests
rspec spec/controllers spec/views
rspec spec/controllers spec/models
David, thanks for the suggestion. One of my model specs was including
Rails.application.routes.url_helpers, so it could evaluate route paths (b/c one
of my models is doing the same, unusual, but supported). Removing the include
fixed the controller spec problem mentioned previously. Of course this broke
the model spec that needed url_helpers, but I was able to work around it by
hard-coding what the expected route should be.
Any idea why including url_helpers in the model spec causes this particular
issue? It would be nice if there wasn't a conflict. I haven't traced through
it enough to understand why the conflict occurs.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users