Problem/Motivation

Soon, the Simpletest UI is going to be removed from core: #2750461: Remove Simpletest UI because we don't want to maintain a graphical test runner

Many of our tests are based on FlagTestBase, and thus, WebTestBase. While we should be able to still run those through the CLI, it's obvious that core is moving towards PHPUnit exclusively.

Proposed resolution

Port FlagTestBase and our remaining tests to PHPUnit classes, such as BrowserTestBase, UnitTestBase, or KernelTestBase.

Remaining tasks

Create patch.

User interface changes

None for users, but Flag tests will no longer be available under admin/development/testing

API changes

FlagTestBase would no longer rely on WebTestBase.

Data model changes

None.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

socketwench created an issue. See original summary.

socketwench’s picture

FileSize
7.25 KB

This will fail, but it's a start.

socketwench’s picture

Right now we're getting a lot of errors similar to this:

There was 1 error:

1) Drupal\Tests\flag\Functional\AdminUITest::testFlagAdmin
Exception: Warning: mkdir(): Permission denied
Drupal\Component\PhpStorage\FileStorage->createDirectory()() (Line: 165)


/var/www/html/core/lib/Drupal/Core/Test/HttpClientMiddleware/TestHttpClientMiddleware.php:44
/var/www/html/vendor/guzzlehttp/promises/src/Promise.php:199
/var/www/html/vendor/guzzlehttp/promises/src/Promise.php:165
/var/www/html/vendor/guzzlehttp/promises/src/FulfilledPromise.php:39
/var/www/html/vendor/guzzlehttp/promises/src/TaskQueue.php:60
/var/www/html/vendor/guzzlehttp/guzzle/src/Handler/CurlMultiHandler.php:96
/var/www/html/vendor/guzzlehttp/guzzle/src/Handler/CurlMultiHandler.php:123
/var/www/html/vendor/guzzlehttp/promises/src/Promise.php:240
/var/www/html/vendor/guzzlehttp/promises/src/Promise.php:217
/var/www/html/vendor/guzzlehttp/promises/src/Promise.php:261
/var/www/html/vendor/guzzlehttp/promises/src/Promise.php:219
/var/www/html/vendor/guzzlehttp/promises/src/Promise.php:62
/var/www/html/vendor/guzzlehttp/guzzle/src/Client.php:129
/var/www/html/vendor/fabpot/goutte/Goutte/Client.php:138
/var/www/html/vendor/symfony/browser-kit/Client.php:297
/var/www/html/vendor/behat/mink-browserkit-driver/src/BrowserKitDriver.php:144
/var/www/html/vendor/behat/mink/src/Session.php:143
/var/www/html/core/tests/Drupal/Tests/BrowserTestBase.php:326
/var/www/html/core/tests/Drupal/Tests/BrowserTestBase.php:429
/var/www/html/modules/flag/tests/src/Functional/FlagTestBase.php:49
/var/www/html/modules/flag/tests/src/Functional/AdminUITest.php:73
socketwench’s picture

Status: Active » Needs review
FileSize
7.12 KB

Reroll.

Status: Needs review » Needs work

The last submitted patch, 4: phpunit_2751053.4.patch, failed testing.

The last submitted patch, 4: phpunit_2751053.4.patch, failed testing.

socketwench’s picture

Status: Needs review » Needs work

The last submitted patch, 7: phpunit_2751053.7.patch, failed testing.

The last submitted patch, 7: phpunit_2751053.7.patch, failed testing.

socketwench’s picture

Not quite sure how to replace drupalPostAJAXForm() in FlagTestbase...

martin107’s picture

@socketwench

Yep you have struck a known core wide problem

Also of note is that there is no replacement for drupalPostAjaxForm.

from https://www.drupal.org/node/2469723

I am posting the full paragraph below.

but it looks like we need to locate the link and "->click()"
.. as always I am posting early in an attempt to be helpful - I will try and find sometime over the weekend to actually do something about this :)

Please note that BrowserTestBase does not yet have feature parity with WebTestBase, in particular the verbose output (#2469721: Add functionality to store browser output to BrowserTestBase).
Also of note is that there is no replacement for drupalPostAjaxForm. The Goutte driver doesn't support JavaScript and we decided instead of adding in hacks to support drupalPostAjaxForm we'd be better served working towards real JavaScript support, in the form of a JavaScript based driver. Step 2 (#2469713: [Needs change record updates] Step 2: Create a JavaScriptTestBase using PhantomJs Driver/Binary) will introduce a JavaScript capable driver and Ajax form interactions will be performed with code like

$this->getSession()->getPage()->find('css', '#somebutton')->click();
If the #some-button element has Ajax behaviors, they'll fire instead of the form submit.

Berdir’s picture

Also of note is that there is no replacement for drupalPostAjaxForm. The Goutte driver doesn't support JavaScript and we decided instead of adding in hacks to support drupalPostAjaxForm we'd be better served working towards real JavaScript support, in the form of a JavaScript based driver. Step 2 (#2469713: [Needs change record updates] Step 2: Create a JavaScriptTestBase using PhantomJs Driver/Binary) will introduce a JavaScript capable driver and Ajax form interactions will be performed with code like

The future is now, JavaScriptTestBase exists :)

So yes, any test that is doing (fake) ajax testing will need to be converted to a JS test. Which in turn will allow for way better tests.

See https://www.chapterthree.com/blog/javascript-testing-comes-to-drupal-8

socketwench’s picture

The future is now, JavaScriptTestBase exists :)

Hm. The only place we use that is when we create the flag with a form instead of directly. If we inherit from JavaScriptTestBase for FlagTestBase, would it impact test performance?

Berdir’s picture

Yes, definitely. JS tests run in an actual browser (phantomjs, no UI but executes all JS and so on), which makes it considerable slower.

I'd recommend to have one dedicated test for the UI and otherwise use the API to create the flags.

socketwench’s picture

martin107’s picture

Here is a candidate for our first test that extends javascriptTestBase

martin107’s picture

I want to break this up into manageable chunks .... here is an simple conversion.

martin107’s picture

Next weeks target.

idebr’s picture

Status: Needs work » Closed (duplicate)