Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Routing error when updating to Rails 3.2.6 or Rspec 2.11.0

After upgrading to Rails 3.2.6 or Rspec 2.11.0, my specs starts to show routing errors like the following:

  4) UsersController GET activate activation code not exist 
     Failure/Error: subject{ get :activate }
     ActionController::RoutingError:
       No route matches {:controller=>"users", :action=>"activate"}

There is also a after each hook error

An error occurred in an after(:each) hook
  RSpec::Mocks::MockExpectationError: (#<EmailSubscriber[...]>).update_attributes({:enable=>true})
    expected: 1 time
    received: 0 times
  occurred at [...]/spec/controllers/users_controller_spec.rb:75:in `block (3 levels) in <top (required)>'

The application in development mode still runs fine.

like image 210
lulalala Avatar asked Jul 13 '12 08:07

lulalala


2 Answers

Both Rspec 2.11.0 and Rails 3.2.6 uses the latest Journey gem (1.0.4). It has some problems, and by explictly lock it to the previous version the spec error disappears.

gem 'journey', '1.0.3'

UPDATE

I recently updated Rails to 3.2.11 with Journey 1.0.4, and all spec passed. My Rspec is 2.11.0 Therefore there is no need to downlock journey anymore, just update Rails.

like image 138
lulalala Avatar answered Nov 08 '22 00:11

lulalala


It appears that the environment is stricter in functional tests than it is in production or development.

In the latter two, it is unable to "know" the parameter names beforehand as they are determined by looking at the according/matching route definition.

In a test, however, one provides the parameter name explicitly. This allows the environment to be more picky.

As that behaviour drifts away from the principle of having a test-env match a prod-env as closely as possible, I consider it a bug and filed an issue accordingly (https://github.com/rails/journey/issues/59).

In order to work around the problem for now, make sure your parameter names match your routes exactly.

I suggest adding the according routes until an outcome is decided in regards to the filed issue. That way, if it's consired a bug and resolved, you just need to remove the routes again - instead of fiddling with your production logic on controller level (which is working flawlessly already).

like image 2
user569825 Avatar answered Nov 08 '22 00:11

user569825