Forum: Ruby on Rails LoginEngine - transaction test oddness

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
05d703f649ef1d07e78d7b479fb4c4ac?d=identicon&s=25 james.adam (Guest)
on 2005-11-12 12:49
(Received via mailing list)
I've just adapted the original salted hashed login generator tests for
the login engine, such that we can now run tests against it and verify
that it behaves nicely, in the same way that you might test any Rails
plugin:

  $ rake test_plugins  # ensuring your test database it set up, etc etc

All the tests pass except one - "test_change_password_with_bad_email".
This test is meant to simulate a user who is trying to change their
password, but where the email to notify them cannot be sent. From what
I can tell, despite the password update being wrapped in a transaction
(user_controller.rb, line 69 in the latest revision) which should get
rolled back upon the mail-related exception,  the password when the
controller action exits has actually been changed! I can't replicate
this behaviour in the console, so I'm throwing it out to some
entreprising plugin debugger out there on the interwebs.

Anyone got any ideas?

- james


------ code snippet follows -----

    def change_password_for(user, params)
      begin
        User.transaction(user) do
          user.change_password(params[:user][:password],
params[:user][:password_confirmation])
          if user.save
            #@user.reload
            #puts "changed password: #{@user.salted_password}"
            if LoginEngine.config(:use_email_notification)
 # ---> the exception gets thrown on the next line
              UserNotify.deliver_change_password(user,
params[:user][:password])
              flash[:notice] = "Updated password emailed to
#{@user.email}"
            else
              flash[:notice] = "Password updated."
            end
            # since sometimes we're changing the password from within
another action/template...
            redirect_to :action => params[:back_to] if params[:back_to]
          else
          end
        end
      rescue
# ---> this is where we should land after the exception, and the
transaction should roll back
# ---> but the password seems to be changed.
        flash[:warning] = 'Password could not be changed at this time.
Please retry.'
      end
    end
46008c33b840b095fc3b9b71d1b566a2?d=identicon&s=25 jhosteny (Guest)
on 2005-11-12 12:49
(Received via mailing list)
James,

	Here's an an obvious question, but are you using InnoDB tables
(assuming you are using MySQL)?

Joe
821395fe70906c8290df7f18ac4ac6cf?d=identicon&s=25 technoweenie (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/9/05, Joseph Hosteny <jhosteny@mac.com> wrote:
> > the login engine, such that we can now run tests against it and verify
> > (user_controller.rb, line 69 in the latest revision) which should get
> > rolled back upon the mail-related exception,  the password when the
> > controller action exits has actually been changed! I can't replicate
> > this behaviour in the console, so I'm throwing it out to some
> > entreprising plugin debugger out there on the interwebs.
> >
> > Anyone got any ideas?
> >
> > - james

Postgresql doesn't allow nested transactions, so you have to disable
transactional fixtures for methods using transactions themselves.

class MyTest < Test::Unit::TestCase
  uses_transaction :test_foo

  def test_foo
  end

  # tests.....
end

I discovered this ages ago (in Rails time), so does anyone know if
there is a better way to do this?

--
rick
http://techno-weenie.net
24d2f8804e6bb4b7ea6bd11e0a586470?d=identicon&s=25 jeremy (Guest)
on 2005-11-12 12:49
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 9, 2005, at 11:34 AM, Rick Olson wrote:
> end
>
> I discovered this ages ago (in Rails time), so does anyone know if
> there is a better way to do this?

You nailed it.  Another way is to segregate the tests which
specifically need to check the results of a rollback into another
test case which has disabled transactional fixtures.

jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDcmaUAQHALep9HFYRAlIdAKChZBQty9B4Px59iOWrRbHDPJCo2gCfaayt
pGgJDQYAsPtxkett1lYIvSo=
=4Cgw
-----END PGP SIGNATURE-----
05d703f649ef1d07e78d7b479fb4c4ac?d=identicon&s=25 james.adam (Guest)
on 2005-11-12 12:49
(Received via mailing list)
To the best of my knowledge the schema.rb file is creating InnoDB
tables, yes - that was one of the first things I checked. What struck
me as most odd is that the method appears to work from the console....

Any other ideas? It would be great to see all tests passing...
This topic is locked and can not be replied to.