Skip to content
This repository

1.0.3 -> 1.0.4 update breaks url_for in tests #42

Closed
atambo opened this Issue July 05, 2012 · 13 comments

6 participants

Alex Tambellini Andrew White Tiago Scolari Aaron Patterson Barnabas Debreczeni dsandstrom
Alex Tambellini
atambo commented July 05, 2012

When upgrading to journey 1.0.4 from 1.0.3 the following code breaks in test environment but works in development environment:

<%= link_to "link", url_for %>

ActionView::Template::Error:
       No route matches {}
Tiago Scolari

I believe I have a related problem, but not in the helper.
A simple test:

describe HomeController do
  it "returns http success" do
    get 'index'
    response.should be_success
  end
end

generates this error:

Failure/Error: get 'index'
  ActionController::RoutingError:
    No route matches {:controller=>"home"}

The controller/route is working, rake routes show the routes correctly, but some tests fail.
Forcing journey on 1.0.3 fixes the tests.

Aaron Patterson
Owner

Can you post an application that demonstrates this problem?

Aaron Patterson
Owner

Also, I think this might be a dup of #20 and #35.

Alex Tambellini
atambo commented July 23, 2012

Could #41 be related?

Alex Tambellini
atambo commented July 23, 2012

@tscolari, are you using https://github.com/apotonick/apotomo or https://github.com/apotonick/cells in your application? Because when I try to reproduce this with a hello world rails app I can't seem to get it to error unless I use apotomo. Anyway, here is a hello world application that uses apotomo and rspec-apotomo to demonstrates this issue:

https://github.com/atambo/journeyapotomobug

I'm going post this issue over in the rspec-apotomo issue tracker as well.

EDIT: Here is the issue on the rspec-apotomo issue tracker:

apotonick/rspec-apotomo#14

Tiago Scolari

@atambo I was not using apotono in this project.
@tenderlove here is an app: https://github.com/tscolari/journey_104_test_app

The rspec for the controllers are failing (ActionController::RoutingError), at the same time that the routes exist and the routing specs pass.

Forcing journey to 1.0.3 will make the ActionController::RoutingError go away (the test still fails because of the view, but that's not the point).

Barnabas Debreczeni
keo commented August 09, 2012

I'm having the same problem. Not with url_for, the way it broke is totally strange and is giving weird RoutingErrors. Going back to journey 1.0.3 fixes it.

Andrew White
Owner

@tscolari may I suggest leaving off the nyan cat formatter next time and try and reproduce in an app with as few as dependencies as possible - all you needed to add was RSpec. Anyway your problem is fixed if you specify the path parameters when calling get - controller specs like functional tests don't test the full stack so they have to recreate the request uri from the parameters passed to the process call and your specs can't generate routes from the supplied controller, action and parameters. The reason is works in 1.0.3 is that it generates an incorrect url like in url in #40. The correct specs are:

describe CacheController do
  describe "GET 'manifest'" do
    it "returns http success" do
      get 'manifest', :mode => 'iphone'
      response.should render_template(:manifest)
    end
  end
end

describe MobileController do
  describe "GET 'index'" do
    it "returns http success" do
      get 'index', :mode => 'web'
      response.should be_success
    end
  end
end

@atambo and @keo I suspect your tests with 1.0.3 are lying to you - you're probably getting incorrect urls as in #40 as well. Can you please check and post code that reproduces the error in 1.0.4 and generates a correct url in 1.0.3.

I'm closing this for the moment as I suspect it's a duplicate of #40, however I'll reopen it if someone can post some example code.

Andrew White pixeltrix closed this August 09, 2012
dsandstrom

I'm receiving similar test environment errors as @atambo. I'm not sure the issue is a duplicate of all the linked errors #40, #20, #35, or #41. I don't believe the tests in 1.0.3 are lying to me. I uploaded two apps to github: https://github.com/dsandstrom/journey_103_test and https://github.com/dsandstrom/journey_104_test . Basically they consist of an application helper method and a corresponding test.

module ApplicationHelper
  def simple_link
    link_to "Page", params.merge(:c => nil)
  end
end

.

require 'spec_helper'
describe ApplicationHelper do
  describe "simple_link" do
    it { simple_link.should == "<a href=\"/assets\">Page</a>" }
  end
end

In journey 1.0.3, the test passes, in 1.0.4, I receive the error:

Failure/Error: it { simple_link.should == "<a href=\"/assets\">Page</a>" }
   ActionController::RoutingError:
     No route matches {:c=>nil}
   # ./app/helpers/application_helper.rb:3:in `simple_link'
   # ./spec/helpers/application_helper_spec.rb:5:in `block (3 levels) in <top (required)>'

The code works in development/production, but not in test. Changing the hash does not have an impact. If I add a proper route like link_to "Page", root_path, {hsh: val} then the route generated has no errors.

Andrew White
Owner

@dsandstrom there are no routes in either of those apps so I'd expect it to generate an error and the only reason it passes on 1.0.3 is that it generates an incorrect url pointing to /assets. Are you suggesting that generating a path to /assets is correct?

dsandstrom

@pixeltrix It is just an example of something I came across. I was thinking it was a bug. What should simple_link generate then? Should I be supplying current_page and params stubs?

Andrew White
Owner

@dsandstrom If there's no routes then it shouldn't generate anything, it should always raise an error. If there's a matched route (i.e. current request) then it should either eliminate the path parameter :c if it is optional or it should clear the query parameter :c.

dsandstrom

@pixeltrix Thanks. I got around it by stubbing url_for self.stub!(:url_for).and_return '/foo' and got something testable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.