AFAICT, there is no testing on D7 of the user password link functionality.

UserPasswordResetTestCase tests:

- the user can request a reset link
- an expired reset link fails
- an incorrect login attempt prefills the reset password request form

But it does not test the workflow of following a reset link and resetting the password.

This could probably be cribbed in part from UserPasswordResetTest::testUserPasswordReset().

Comments

attiks’s picture

attiks CreditAttribution: attiks commented

See #2207497: UserPasswordResetTest::testUserPasswordReset() is bogus, the test you mention is not working, although it has the expected result.

attiks’s picture

attiks CreditAttribution: attiks commented
Priority: Normal » Major

The biggest problem with testing this is that drupal_get_hash_salt is used and that function uses hash('sha256', serialize($databases)) as the hash, the big problem is that $databases is different between the test code and the code being executed.

The underlying problem is that we should add $drupal_hash_salt to settings.php and don't rely on something magic as the database array to generate a salt. So the proper fix should be to patch the install module to insert a line into settings.php so $drupal_hash_salt is fixed.

joachim’s picture

joachim CreditAttribution: joachim commented

Isn't the reset workflow something that would be tested in the testing browser, using drupalPost()? Is the $databases thing a problem because we need to somehow get the reset URL that the system wants to email to the user, and we have to fake it up? Can we intercept the mail in some way to get the URL?

attiks’s picture

attiks CreditAttribution: attiks commented

The problem is that the simpletest prefix is injected at some point into the $databases, but part of a request is done using the normal $databases since simpletest has to report back the status of each test run. The underlying problem (and fixed in Drupal 8) is that the $hash is based on the database configuration.

For the moment we have a partial solution, but it does depend way too much on the configuration, see #2207161-13: Automated testing, the only proper solution is how it is solved in D8, insert the $drupal_hash_salt with a random value in settings.php at install time.

PS: For some reason the variable is inserted when doing an upgrade from D6 to D7.

JvE’s picture

JvE CreditAttribution: JvE commented

Ok, only after uploading a patch with the described tests to #2207497: UserPasswordResetTest::testUserPasswordReset() is bogus do I find this issue.

@joachim, can you check there if that patch works for you?