Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I am trying to login a user with DrupalWebTestCase::drupalLogin and it's failing. Here is my simpletest callback:
$create_j_entity_type_user = $this->drupalCreateUser(array('create j-entity types'));
$this->drupalLogin($create_j_entity_type_user);
The output of the drupalLogin():
User created with name zPUkpgzN and pass 6NXRDGWy5k Pass
GET http://www.example.com/user returned 200 (1 byte). Pass
Valid HTML found on "http://www.example.com/user" Pass
Failed to set field name to zPUkpgzN Fail
Failed to set field pass to 6NXRDGWy5k Fail
Found the Log in button Fail
Found the requested form fields at user Fail
User zPUkpgzN successfully logged in. FailThis is the entirity of my callback, I haven't even done anything else yet. I cannot understand why drupalLogin() is failing. I am executing the code on a non-language domain (though the site itself is multilingual), and have set $base_path in settings.php, but no matter what I do, this fails.
Comments
Comment #1
Jaypan CreditAttribution: Jaypan commentedMerged with original post.
Comment #2
phl3tch CreditAttribution: phl3tch commentedI've been hammering at this same issue myself for about three days, and I think I'm on the trail of a solution. It seems that when curlExec() calls curlInitialize to set up the necessary curlopts (/modules/simpletest/drupal_web_test_case.php, line 1608), the settings are getting overwritten or ignored later. Specifically, CURLOPT_RETURNTRANSFER, which must be set to TRUE, otherwise curl will return a Boolean instead of the data that Simpletest is trying to make assertions against.
I can't provide a patch because I'm not 100% sure what's going on here, but if I add:
$curl_options[CURLOPT_RETURNTRANSFER] = TRUE;...right before line 1631, well, let's just say that things fail less spectacularly. At least on my system, it no longer complains that it can't set fields name and password. It still fails to log in, however.
Would love it if some other folks would take a look at this. I'm about to pull my hair out.
Comment #3
Albert Volkman CreditAttribution: Albert Volkman commentedI too am having this issue. It almost appears that its not using the generated database, and instead using the main database. Try manually setting the test's username/password to your Drupal install's user 1.
Comment #4
Jaypan CreditAttribution: Jaypan commentedHi Albert
That makes sense, as one of the errors I'm getting is that the field on a user could not be set, but in a clean install, there should be no fields on the user, which has definitely been confusing me.
Can you give more information on what you mean by setting the test user to user 1? Thank you.
Comment #5
Jaypan CreditAttribution: Jaypan commentedI'm setting this to major, for while it doesn't prevent functionality on a site, it prevents testing for bugs, which could in turn allow for potentially serious bugs.
Comment #5.0
Jaypan CreditAttribution: Jaypan commentedIncorrect messages
Comment #6
marcingy CreditAttribution: marcingy commentedCore tests are not failing on d.o so I can't see how this is major.
Comment #7
Jaypan CreditAttribution: Jaypan commentedAhh, so since it works on DO, our sites are irrelevant. Might as well close the bug then.
Comment #8
marcingy CreditAttribution: marcingy commentedHmm no but it is not a major bug according to d.o bug classifications , but it is something that still needs to be looked at and fixed.
Comment #9
marcingy CreditAttribution: marcingy commentedComment #10
Jaypan CreditAttribution: Jaypan commentedI personally disagree, as a lack of testing can mean that a whole site can go down due to a bug, which fits the classifications.
Here is my entire test class:
And here is the test result:
Edit: Looking more at the test results, the login page is returning a 200 status, but the returned value is a single byte, the integer '1', as can be seen in the verbose message:
This is in line with CrackWilding's comment in post #2:
It appears that a boolean is being returned instead of the page value. This also means that it's not likely my regular database is being used. As such, I edited this line of drupal_web_test_case.php:
To this:
And the login did succeed, although like CrackWilding, I am still seeing other errors.
Comment #11
Jaypan CreditAttribution: Jaypan commentedTurns out this issue has already been fixed, and this thread is a duplicate of http://drupal.org/node/1671200
Comment #12
Umayal CreditAttribution: Umayal commentedI have posted my code in http://drupal.org/node/1791220
anybody help me to complete the basic test operation.
Comment #13
kilogauss CreditAttribution: kilogauss commentedUpdating to Drupal 7.19 resolved this for me.
Comment #14
victor-shelepen CreditAttribution: victor-shelepen commentedI am making tests for the module - locale, Drupal 8. I see the same problems. I've looked over duplicated task. I've not found the right solution.
This lines.
Prints this:
I understand that many people work with. But it strange for me why I have problems with.
Comment #15
victor-shelepen CreditAttribution: victor-shelepen commentedI work on Ubuntu 13.04. Maybe I have differ curl default settings. Could I put this settings into php.ini?
Comment #15.0
victor-shelepen CreditAttribution: victor-shelepen commentedRemoving unneeded and incorrect comment.
Comment #17
kirankumar_k CreditAttribution: kirankumar_k commentedI have run the test and I got 13 passes(In green color) where status is showing green tick mark and 3 failed(In red color) where status is showing in red X.
The 3 failed results are as follows
"Found the Save button"
"Found the requested form fields at admin/main/xxx/settings"
"Product created."
which are caused by the below code
$edit = array(
'textbox1' => $this->randomName(8),
'textbox2' => $this->randomName(8),
'select' => array_rand(array(
'opt1' => t('opt1'),
'opt2' => t('opt2'),
'opt3' => t('opt3'),
)),
);
$this->drupalPost('admin/main/xxx/settings',$edit,t('Save'));
Even I have given proper form permissions and when i opened the form in verbose it is opened properly, I am not able to understand what is the issue. Please help me in this asap.
Comment #25
quietone CreditAttribution: quietone as a volunteer commentedTriaging issues in simpletest.module as part of the Bug Smash Initiative to determine if they should be in the Simpletest Project or core.
This looks like it a Phpunit issue, changing component.
Comment #26
mondrakeSimpletest is gone. Latest comments seem more request for support than addressing a bug, anyway. This issue is stale and obsolete. Closing, open support requests in case.