Problem/Motivation
Testing Drupal\Tests\media_library\FunctionalJavascript\WidgetViewsTest
F 1 / 1 (100%)
Time: 01:57.676, Memory: 4.00 MB
There was 1 failure:
1) Drupal\Tests\media_library\FunctionalJavascript\WidgetViewsTest::testWidgetViews
"Loading grid view." not found
Failed asserting that a boolean is not empty.
/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:121
/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:55
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/MediaLibraryTestBase.php:65
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/MediaLibraryTestBase.php:409
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/WidgetViewsTest.php:118
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:726
— https://www.drupal.org/pift-ci-job/2507467
1) Drupal\Tests\media_library\FunctionalJavascript\WidgetViewsTest::testWidgetViews
WebDriver\Exception\CurlExec: Curl error thrown for http POST to http://chromedriver-jenkins-drupal-patches-187886:9515/session/73f6b5d5a73c8b7035b4362195d8782f/element/0.27412969624553574-76/click
Retries: 10 and last result:
{"sessionId":"73f6b5d5a73c8b7035b4362195d8782f","status":10,"value":{"message":"stale element reference: element is not attached to the page document\n (Session info: headless chrome=106.0.5249.103)\n (Driver info: chromedriver=106.0.5249.61 (511755355844955cd3e264779baf0dd38212a4d0-refs/branch-heads/5249@{#569}),platform=Linux 4.9.0-0.bpo.6-amd64 x86_64)"}}
/var/www/html/vendor/instaclick/php-webdriver/lib/WebDriver/Exception.php:198
/var/www/html/core/tests/Drupal/FunctionalJavascriptTests/WebDriverCurlService.php:146
/var/www/html/vendor/instaclick/php-webdriver/lib/WebDriver/AbstractWebDriver.php:125
/var/www/html/vendor/instaclick/php-webdriver/lib/WebDriver/AbstractWebDriver.php:234
/var/www/html/vendor/instaclick/php-webdriver/lib/WebDriver/Container.php:241
/var/www/html/vendor/behat/mink-selenium2-driver/src/Selenium2Driver.php:805
/var/www/html/vendor/behat/mink-selenium2-driver/src/Selenium2Driver.php:729
/var/www/html/vendor/behat/mink/src/Element/NodeElement.php:185
/var/www/html/vendor/behat/mink/src/Element/TraversableElement.php:210
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/WidgetViewsTest.php:123
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
Steps to reproduce
In another galaxy issue, far, far away, I reproduced the first error and took screenshots when the assertion fails. That looks like this:

So the assertion is done whilst the AJAX request hasn't finished yet.
The second failure can only happen for two reasons:
1. The element under test is removed from the DOM.
2. The page changed whilst after getting the element under test.
In this patch I took screenshots if there's a CurlExec is thrown. Those look like this:

The select for Dog is still present, which leaves us with only option 2.
Upon closer inspection, the page actually does get (AJAX-)reloaded with the $page->pressButton('Apply filters'); just above our random failure point.
Proposed resolution
Add a $this->assertSession()->assertWaitOnAjaxRequest(); before both problematic code lines to make sure we're testing the page we're expecting to test.
For the second failure, we can now also change the waitFor(No)Text with pageText(Not)Contains, since the waiting is now, more reliable done with the assertWaitOnAjaxRequest()
Since both random failures are related in their cause and #5 proves they are both occuring with our (gazillion) test runs, I believe I can fly we can fix and test their "fixed-ness" in one go.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | 3317378-10.patch | 1.64 KB | spokje |
Comments
Comment #2
wim leersI don't see what could possibly be wrong here.
I think this was just a random failure where this click literally didn't yield a result after even 10 seconds 🙈
Comment #4
spokjeComment #5
spokjeLet's first proof that running
WidgetViewsTest::testWidgetViewsstill produces random test failures.Here's a patch that runs
WidgetViewsTest::testWidgetViews2000 times.Comment #6
spokjeSo besides the SQLite
SQLSTATE[HY000]: General error: 5 database is lockederror, which I see happening a lot when doing loads of tests on a SQLite environment, we have a new contender besides the one in the current IS:Comment #7
spokjeComment #8
spokjeComment #9
spokjeThe normal routine to prove a random failure is fixed is to run the failing patch and the patch with the fix at the same time, whilst the latter has to have ~8000 - 10.000 failure free runs to prove it's credibility.
So let's do that here, and double the amount of runs on our fix patch, since especially the first failure in the IS isn't too common anymore.
Comment #10
spokjeThats 16 * 2000 = 32.000 runs without a test failure.
Good enough for me, here's the actual patch.
Comment #11
spokjeComment #12
spokjeComment #13
spokjeComment #14
spokjeComment #15
smustgrave commentedAny improvement is better!
Comment #18
lauriiiCommitted c167772 and pushed to 11.x. Cherry-picked to 10.1.x. Thanks!
The commit message 🤦♂️
Comment #19
spokjenonCorrectEscapedAndTurnedIntoCamelCaseCommitMessagesAreGoingToBeBigIn2023