CODEWITHSUNDEEP
mysqlruby-on-railsrspecdevisecapybara
Eric Baldwin
Eric Baldwin

Reputation: 3491

in Ruby on Rails, updated gem causing mysql database rollback in formerly passing Capybara test

The following spec used to pass:

it "should allow me to register" do
  fill_in "First name",         with: "John"
  fill_in "Last name",         with: "Peters"
  fill_in "Email",        with: "[email protected]"
  fill_in "Password",     with: "foobar"
  fill_in "Password confirmation", with: "foobar"
  expect { click_button submit }.to change(User, :count).by(1)
end

With a test.log output of:

Started GET "/users/sign_up" for 127.0.0.1 at 2013-08-16 13:12:45 -0400
Processing by RegistrationsController#new as HTML
  Rendered users/shared/_service.html.haml (1.9ms)
  Rendered users/registrations/_newfields.haml (149.9ms)
  Rendered users/shared/_links.haml (3.9ms)
  Rendered users/registrations/new.html.haml within layouts/application (180.3ms)
  Rendered shared/_header.haml (10.0ms)
  Rendered shared/_footer.haml (12.4ms)
Completed 200 OK in 411ms (Views: 331.7ms | ActiveRecord: 30.0ms)
   (120.9ms)  SELECT COUNT(*) FROM `users` 
Started POST "/users" for 127.0.0.1 at 2013-08-16 13:12:47 -0400
Processing by RegistrationsController#create as HTML
  Parameters: {"utf8"=>"✓", "user"=>{"first_name"=>"John", "last_name"=>"Peters", "email"=>"[email protected]", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}, "commit"=>"Sign up"}
   (0.4ms)  BEGIN
  User Exists (0.4ms)  SELECT 1 AS one FROM `users` WHERE `users`.`email` = BINARY '[email protected]' LIMIT 1
  SQL (1.5ms)  INSERT INTO `users` (<values>) VALUES (NULL, NULL, NULL, NULL, 'USA', '2013-08-16 17:12:47', NULL, NULL, '[email protected]', '$2a$10$E4/LZAvbf7HvFobBjFQxjOnHuO8cnBNJzMPQ3MMT9oVnou98DGqty', 'John', 1, '--- []\n', NULL, 'Peters', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 0, NULL, '2013-08-16 17:12:47', NULL)
   (30.4ms)  COMMIT
   (0.1ms)  BEGIN
   (0.5ms)  UPDATE `users` SET `last_sign_in_at` = '2013-08-16 17:12:47', `current_sign_in_at` = '2013-08-16 17:12:47', `last_sign_in_ip` = '127.0.0.1', `current_sign_in_ip` = '127.0.0.1', `sign_in_count` = 1, `updated_at` = '2013-08-16 17:12:47', `interest_areas` = '--- []\n' WHERE `users`.`id` = 1
   (0.5ms)  COMMIT
Redirected to http://www.example.com/
Completed 302 Found in 210ms (ActiveRecord: 0.0ms)
Started GET "/" for 127.0.0.1 at 2013-08-16 13:12:47 -0400

However, after running bundle update, the test now fails with the error:

 Failure/Error: expect { click_button submit }.to change(User, :count).by(1)
   count should have been changed by 1, but was changed by 0

And test.log output of:

Started GET "/users/sign_up" for 127.0.0.1 at 2013-08-16 13:09:19 -0400
Processing by RegistrationsController#new as HTML
  Rendered users/shared/_service.html.haml (2.0ms)
  Rendered users/registrations/_newfields.haml (183.5ms)
  Rendered users/shared/_links.haml (5.8ms)
  Rendered users/registrations/new.html.haml within layouts/application (220.0ms)
  Rendered shared/_header.haml (10.2ms)
  Rendered shared/_footer.haml (10.7ms)
Completed 200 OK in 623ms (Views: 522.2ms | ActiveRecord: 57.1ms)
   (17.3ms)  SELECT COUNT(*) FROM `users` 
Started POST "/users" for 127.0.0.1 at 2013-08-16 13:09:20 -0400
Processing by RegistrationsController#create as HTML
  Parameters: {"utf8"=>"✓", "user"=>{"first_name"=>"John", "last_name"=>"Peters", "email"=>"[email protected]", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}, "commit"=>"Sign up"}
   (0.2ms)  BEGIN
   (0.1ms)  ROLLBACK
Redirected to http://www.example.com/users/sign_up
Completed 302 Found in 11ms (ActiveRecord: 0.3ms)
Started GET "/users/sign_up" for 127.0.0.1 at 2013-08-16 13:09:20 -0400

The divergence occurs after the BEGIN line in the database queries; the new version does a ROLLBACK immediately after.

Only the gems have changed between the passing case and the failing case. The diff between the two commits (mainly a difference between their Gemfile.lock files) can be found here: http://pastie.org/private/d4a49zoegu0j3faigfjfw

Does anyone know whether updating any of those gems could have caused this error?

Edit - Here is the Registration Controller's #create code:

  def create
    build_resource
    if resource.save
      if resource.active_for_authentication?
        set_flash_message :notice, :signed_up if is_navigational_format?
        sign_up(resource_name, resource)
        respond_with resource, :location => after_sign_up_path_for(resource)
      else
        set_flash_message :notice, :"signed_up_but_#{resource.inactive_message}" if is_navigational_format?
        expire_session_data_after_sign_in!
        respond_with resource, :location => after_inactive_sign_up_path_for(resource)
      end
    else
      clean_up_passwords resource
      ## logic of path
      redirect_to new_user_registration_path, alert: resource.errors.full_messages.join('<br />')
    end
  end

Upvotes: 1

Views: 166

Answers (2)

Eric Baldwin
Eric Baldwin

Reputation: 3491

I simply reverted to my old Gemfile.lock, emptied my gem set, and installed them all again (effectively reverting them to their old versions).

Upvotes: 0

Peter Alfvin
Peter Alfvin

Reputation: 29409

Based solely on general experience and not on specific knowledge of those gem version changes, I can say with some confidence that updating that many gems, including at least two gems with a major version change (i.e. delayed_job*), could have caused this error. :-) I know that's not much help, but if you post the related code (e.g. your RegistrationsController), I bet the community can help you find the issue fairly quickly and perhaps help others in the future.

Upvotes: 1

Related Questions