[rspec-users] [rails] url_for host and protocol not set when full spec suite run

Michael Kintzer rockrep at yahoo.com
Thu Sep 16 13:34:10 EDT 2010

From: David Chelimsky <dchelimsky at gmail.com>
To: rspec-users <rspec-users at rubyforge.org>
Sent: Thu, September 16, 2010 4:59:26 AM
Subject: Re: [rspec-users] [rails] url_for host and protocol not set when full 
spec suite run

On Sep 16, 2010, at 1:44 AM, Michael Kintzer wrote:

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:
>rspec (2.0.0.beta.19)
>>rails (3.0.0)
>>authlogic (2.1.6)
>>bartt-ssl_requirement (1.2.3)
>>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.

Rails.application.routes.url_helpers is a global object, so if the spec is doing 
anything to change its state that might cause trouble. That's all I can think 
of. How are you including them?

I was including them with "include Rails.application.routes.url_helpers" which 
is the Rails 3 recommendation as specified in ActionController::UrlWriter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100916/7003403c/attachment-0001.html>

More information about the rspec-users mailing list