Re: Salted Login Generator - Bad email failures

Joseph Hosteny
Mon, 23 May 2005 13:14:30 -0000

On May 23, 2005, at 1:53 AM, nikolaus heger wrote:

> Hi!
>
> I am using the Salted Login Generator, largely without problems.
> However, there are two unit test failures when running
> rake on a pristine, clean SLG install:
>
>   1) Failure:
> test_change_password(UserControllerTest)
>     [/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/
> action_controller/deprecated_assertions.rb:23:in
`assert_session_has''
>      ./test/functional/user_controller_test.rb:186:in
> `do_change_password''
>      ./test/functional/user_controller_test.rb:194:in
> `test_change_password'']:
> <"user"> is not in the session
<#<ActionController::TestSession:
> 0x25960e0
>  @attributes={"user"=>nil, "flash"=>{}}>>
>
>   2) Failure:
> test_signup(UserControllerTest)
>     [/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/
> action_controller/assertions.rb:44:in `assert_response''
>      /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/
> action_controller/deprecated_assertions.rb:13:in `assert_redirect''
>      /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.8.1/lib/
> action_controller/deprecated_assertions.rb:98:in
`assert_redirect_url''
>      ./test/functional/user_controller_test.rb:37:in
`do_test_signup''
>      ./test/functional/user_controller_test.rb:145:in
`test_signup'']:
> Expected response to be a <:redirect>, but was <200>
>
> I have determined that both of those failures come as a result of
> ActionMailer::Base.inject_one_error = true
> not being handled correctly. In both cases things get stored in the
> database even though a confirmation email could not be sent.
>

Your database must support transactions, or else the test code will
not work. For MySQL, make sure the table type is InnoDB. The intent
is that the changes to the database are rolled back if the email
cannot be sent.

> In the signup test (2), the user is saved even though there were
> delivery problems, which causes test after to fail: The first test
> (with bad_email = true) saves a user when it should not - or at
> least doesn''t delete the newly created user after figuring out
that
> the email was bad.
> The second test (bad_email = false) then fails because the user
> name is already taken.
> If i remove the test with bad email the second test does not cause
> a failure.
> BTW, i also replaced assert_redirect_url with the non-deprecated
> version:
> assert_redirected_to({:action => "login"}) # no difference
>
> I also added an assert that ensures that the test with the actual
> error fails rather than the one after:
>         get :logout
>         assert_session_has_no "user"
>     ### NEW CODE
>     if bad_email
>         # logging in with the changed password should not work on
> bad email
>         post :login, "user" => { "login" =>
"bob", "password" =>
> "changed_password" }
>         assert_session_has_no "user"
>     end
>         ### END NEW CODE
>     if not bad_password and not bad_email.....
>
>
> in (1) the user is saved despite email problems again. This time,
> the changed password is saved even though the email could not be
> delivered. Judging from the code, this is the intended - but
> incorrect - behavior.
>
> What is a bit surprising is that the unit tests test for this case
> and find out that it''s not being handled correctly, yet the error
> is still in the code... ?!
>
> Am i doing something really wrong, or do i just need to fix those
> issues?
>

Once you change the table type, these tests should pass. The unit
test code does express the intended behavior.

-joe

>     Nik
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Joseph Hosteny
jhosteny-ee4meeAH724@public.gmane.org