In #2432911: Provide test coverage to prove that a third party authentication provider does not automatically start a session tests were added to check if no cookies are set if a user authenticates using basic authentication. It was discovered that the cookies from a previous test were still present at the start of a new test.

In WebTestBase::curlHeaderCallback() the $this->cookies property is filled whenever a cookie is set on the request but these are never cleared to simulate the browser persisting the cookies inbetween requests. We should make sure to clear this before starting a new test.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Bug
Unfrozen changes Unfrozen because it only changes tests.
Disruption Not disruptive
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pfrenssen’s picture

Status: Active » Needs review
FileSize
1.8 KB
2.26 KB

Here's a fix + test. Since the $this->cookies property seems to be wholly untested I also added a test to see if the name and value of the cookie are correct.

The last submitted patch, 1: 2491353-1-test-only.patch, failed testing.

znerol’s picture

  1. +++ b/core/modules/simpletest/src/Tests/BrowserTest.php
    @@ -65,4 +65,34 @@ function testXPathEscaping() {
    +    // Check that the name and value of the cookie match the request data.
    +    $cookie_headers = preg_grep('/^Set-Cookie: ([^=]+)=(.+)/', $this->headers);
    +    $cookie_header = reset($cookie_headers);
    

    Use $this->drupalGetHeader() unless there is a strong reason against that.

  2. +++ b/core/modules/simpletest/src/WebTestBase.php
    @@ -1089,6 +1089,7 @@ protected function tearDown() {
         $this->curlCookies = array();
    +    $this->cookies = array();
    

    The $cookies property is not initialized on declaration. In order to maintain consistency (each test should work with the same initial value), I think either the $cookies property needs to be set to NULL here or it should to be initialized to an empty array on declaration.

pfrenssen’s picture

FileSize
2.64 KB
1.82 KB
  1. I didn't realize there was a method for that, thanks for pointing it out!
  2. I initialize it to an array, since that matches the documentation for the property. I'm using the old array() syntax instead of [] to be consistent with the rest of the file.
pfrenssen’s picture

This patch contains only the test, this should fail.

Status: Needs review » Needs work

The last submitted patch, 5: 2491353-4-test-only.patch, failed testing.

pfrenssen’s picture

Status: Needs work » Needs review
znerol’s picture

Status: Needs review » Reviewed & tested by the community

Thanks!

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/core/modules/simpletest/src/Tests/BrowserTest.php
@@ -65,4 +65,40 @@ function testXPathEscaping() {
+  public function testCookies() {
...
+   * In order for this test to be effective it should always run after the
+   * testCookies() test.
...
+  public function testCookieDoesNotBleed() {

Let's set a static in testCookies() and assert it's value in testCookieDoesNotBleed() so we can be sure we're testing something - or if someone has the bright idea of parallelising all the individual test methods during a run this breaks.

pfrenssen’s picture

Status: Needs work » Needs review
FileSize
2.52 KB
3.16 KB
3.16 KB
1.51 KB

Al right I added a static to track whether testCookies() actually runs before testCookieDoesNotBleed(). This will fail to alert someone running the tests in parallel that this behaviour is now untested. Probably we will have long moved to BrowserTestBase before running test methods in parallel becomes a real necessity.

I added two failing tests now: one to prove that the test detects the issue, and the other to prove that a failure will occur if testCookies() does not run before testCookieDoesNotBleed().

The last submitted patch, 10: 2491353-10-test-reversed.patch, failed testing.

almaudoh’s picture

Status: Needs review » Needs work

Core maintainers comments addressed and reversed test sequence fails as desired. I would have set this to RTBC, but:

+++ b/core/modules/simpletest/src/Tests/BrowserTest.php
@@ -65,4 +73,44 @@ function testXPathEscaping() {
+    $this->assertTrue(self::$cookieSet, 'A cookie has been set in a previous test.');

'A cookie has been set in a previous test.' does not exactly tell why the assertion failed. A more explicit message like 'testCookieDoesNotBleed() runs after testCookie()' or so would be more helpful, especially in the case of parallel testing.

znerol’s picture

+++ b/core/modules/simpletest/src/Tests/BrowserTest.php
@@ -65,4 +73,44 @@ function testXPathEscaping() {
+    self::$cookieSet = TRUE;
...
+   * @see self::testCookies()
...
+    $this->assertTrue(self::$cookieSet, 'A cookie has been set in a previous test.');

I'm not quite sure and I cannot find any reliable source, but I feel that static is preferable over self nowadays. search query.

znerol’s picture

Re #12 perhaps something like Test methods are run in the expected order?

pfrenssen’s picture

Assigned: Unassigned » pfrenssen
Issue tags: +DrupalCampSpain2015
pfrenssen’s picture

Assigned: pfrenssen » Unassigned
Status: Needs work » Needs review
FileSize
2.53 KB
3.18 KB
1.07 KB

Addressed the remarks.

The last submitted patch, 16: 2491353-16-test-only.patch, failed testing.

znerol’s picture

Status: Needs review » Reviewed & tested by the community

Thanks!

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed ca5fced and pushed to 8.0.x. Thanks!

  • alexpott committed ca5fced on 8.0.x
    Issue #2491353 by pfrenssen, znerol: Cookies from previous tests are...
David_Rothstein’s picture

Version: 8.0.x-dev » 7.x-dev
Status: Fixed » Patch (to be ported)
Issue tags: +Needs backport to D7

I am guessing this needs to be backported, right?

  • alexpott committed ca5fced on 8.1.x
    Issue #2491353 by pfrenssen, znerol: Cookies from previous tests are...
pietmarcus’s picture

I have backported this issue to Drupal 7. Here is a testonly patch, that will fail.

pietmarcus’s picture

Status: Patch (to be ported) » Needs review
FileSize
3.56 KB

Here is the patch itself. Please review.

pietmarcus’s picture

Let me upload the testonly patch again, so it is picked up by the test-server.

Status: Needs review » Needs work

The last submitted patch, 25: 2491353-cookie-clearing-d7-testonly.patch, failed testing.

pietmarcus’s picture

Status: Needs work » Needs review

As expected, the test-only patch failed. #24 passed, so I'm changing the status to Needs review again.

The last submitted patch, 23: 2491353-cookie-clearing-d7-testonly.patch, failed testing.

Anonymous’s picture

This patch applied in my localhost. I qued the test again.

Status: Needs review » Needs work

The last submitted patch, 25: 2491353-cookie-clearing-d7-testonly.patch, failed testing.

pietmarcus’s picture

Status: Needs work » Needs review

The test only patch failed again. #24, the patch with the fix is the patch up for review.

znerol’s picture

Status: Needs review » Reviewed & tested by the community

Nice, thanks.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review
+    // Set a flag indicating that a cookie has been set in this test.
+    // @see testCookieDoesNotBleed()
+    static::$cookieSet = TRUE;
....
+    $this->assertTrue(static::$cookieSet, 'Tests have been executed in the expected order.');

This won't work on PHP 5.2, which we technically still support. Is there any reason self:: can't just be used instead?

Also, minor, but the @see should actually be a sentence using "See" since it's an inline code comment. I would probably include the class name too, in other words: "See SimpleTestBrowserTestCase::testCookieDoesNotBleed()."

znerol’s picture

Oh, do we even have 5.2 test runners on CI?

pietmarcus’s picture

I have changed the patch as suggested in #33. Here are a new patch and the interdiff.

Please review!

Status: Needs review » Needs work

The last submitted patch, 35: 2491353-cookie-clearing-d7-35.patch, failed testing.

pietmarcus’s picture

Status: Needs work » Needs review

The test that failed has nothing to do with the patch, so marking Needs review again.

Anonymous’s picture

I qued for test again.

David_Rothstein’s picture

Status: Needs review » Needs work

Looking better, but:

+    // @see See testCookieDoesNotBleed()

The @see should not be there. Just the "See". And a period at the end of the sentence.

+   * @see See self::testCookies()
+   */
+  public function testCookieDoesNotBleed() {

Since this one is part of the function documentation it should use @see but according to https://www.drupal.org/coding-standards/docs#see. So it should just be "@see SimpleTestBrowserTestCase::testCookies()"

+    $this->assertTrue(static::$cookieSet, 'Tests have been executed in the expected order.');

This one will need to use "self::" also.

David_Rothstein’s picture

Oh, do we even have 5.2 test runners on CI?

Not currently, but I've heard rumors they could exist in the future :) Bottom line, it's worth keeping the tests compatible with PHP 5.2 (like the rest of Drupal) if we can.

pietmarcus’s picture

Status: Needs work » Needs review
FileSize
1.13 KB
3.58 KB

Fixed the comments made in #39. Please review.

znerol’s picture

Status: Needs review » Reviewed & tested by the community

Looks good, thanks.

Fabianx’s picture

Priority: Normal » Major
Issue tags: +Pending Drupal 7 commit
+++ b/modules/simpletest/simpletest.test
@@ -380,6 +388,46 @@ EOF;
+   * @see self::testCookies().

This should still say SimpleTestBrowserTestCase::testCookies.

Could be fixed on commit, though.

stefan.r’s picture

+1, looks great

Fabianx’s picture

Still RTBC and marked for commit.

stefan.r’s picture

Assigned: pietmarcus » Unassigned

  • Fabianx committed 1fea8c8 on 7.x
    Issue #2491353 by pfrenssen, pietmarcus, znerol, David_Rothstein:...
Fabianx’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: -Pending Drupal 7 commit +7.50 release notes

Committed and pushed to 7.x! Thanks!

Added to CHANGELOG.txt so that module authors know that their tests could have a side effect fixed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.