Use Symfony's simple-phpunit

You mean no more composer run-script drupal-phpunit-upgrade whenever switching core branches? Yes please! 👏

So testing_ui core module can expose dependency on simple-phpunit? and no more pain with drupal-phpunit-upgrade and less code to maintain

Uhm, Symfony phpunit-bridge seems even more conservative than Drupal in the PHPUnit version used to run tests.

Trying to summarize below:

In terms of simpletest ui, we can add a hook_requirements at phase 'install' and prevent it from being installed if the class is missing.

Reroll and PHPCS fixes.

Seeing following error on each test run.

11:31:37   [Symfony\Component\Console\Exception\RuntimeException]  
11:31:37   Not enough arguments (missing: "packages").             
11:31:37                                                 

Don't know if it matters, but it looks like the PHPUnit version being loaded and run is 5.7.27 - not sure there's code to support that one

PHPUnit 5.7.27 by Sebastian Bergmann and contributors.

Testing Drupal\Tests\aggregator\Functional\AddFeedTest
...                                                                 3 / 3 (100%)

Time: 33.99 seconds, Memory: 4.00MB

+++ b/core/tests/bootstrap.php
@@ -151,6 +151,20 @@ function drupal_phpunit_populate_class_loader() {
+if (!class_exists('PHPUnit_Runner_Version') && !class_exists('PHPUnit\Runner\Version')) {

PHPUnit_Runner_Version is old stuff

Tired of things with the word 'simple' in their name.

That is all.

Adventures in simple-phpunit-land….

Note that these experiments don’t use the patch in #26.

It turns out that symfony/phpunit-bridge has different PHP requirements than other symphony components, so we can (and should) bump it right up to 4.3.x. https://packagist.org/packages/symfony/phpunit-bridge

So we do that by changing core/composer.json to have symfony/phpunit-bridge version constraint of @stable.

Then we do the composer shuffle:

$ composer config platform.php 7.0.8
$ composer update symfony/phpunit-bridge —with-dependencies

This gives us:

  - Updating symfony/phpunit-bridge (v3.4.26 => v4.3.1): Loading from cache

Now we can run simple-phpunit. I’ve pinned us to PHPUnit 6.5 since we’re not trying to target other PHPUnit versions in this issue, just get simple-phpunit working.

$ SYMFONY_PHPUNIT_VERSION=6.5 ./vendor/bin/simple-phpunit -c core/ --testsuite unit

This results in a bunch of fails based on deprecations, including this one which is my favorite:

  1x: The "Drupal\Tests\Listeners\DrupalListener" class extends "PHPUnit\Framework\BaseTestListener" that is deprecated Use TestListenerDefaultImplementation trait instead.
    1x in DebugClassLoader::loadClass from Symfony\Component\Debug

This deprecation was introduced in 6.4, so we can change it safely if our minimum PHPUnit is 6.5. https://phpunit.de/announcements/phpunit-7.html

But it's important to note that this deprecation isn't discovered through @trigger_error(). :-)

We can fix this deprecation in #3063182: Remove PHPUnit 4.8 class aliasing BC layer

There’s also a fail that looks like this:

........................................................FF.  2832 / 17904 ( 15%)
.............................................FFF
THE ERROR HANDLER HAS CHANGED!

This typically happens when a test class does not have a result object. That happens when the test errors out and doesn’t complete. So in this case:

[21-Jun-2019 12:04:06 Australia/Sydney] PHP Fatal error:  Cannot redeclare drupal_valid_test_ua() (previously declared in /Users/paul/projects/drupal/core/tests/Drupal/Tests/Core/DrupalKernel/DrupalKernelTest.php:248) in /Users/paul/projects/drupal/core/includes/bootstrap.inc on line 643

And there’s an issue for that: #3054649: DrupalKernelTest results in ERROR HANDLER CHANGED! and/or #3038513: Move drupal_generate_test_ua() into the test system

Applying the patch from #3054649-9: DrupalKernelTest results in ERROR HANDLER CHANGED! we get just a ton of deprecation fails and fails related to the UI test runner.

No doubt many of the deprecation fails relate to the upstream issue @alexpott mentions in #19. https://github.com/symfony/symfony/pull/31649 is targeting 3.4, but we don’t really need that as shown above.

Here concludeth the experimentation. I’m currently trying to figure out if we like this tool better or if we want to have run-tests.sh make code coverage for us: #2974911: Allow run-tests.sh to generate coverage reports

In that issue, we use phpdbg instead of php to run phpunit, and I’m not sure how that will map to using simple-phpunit instead. Also if we don't have a dependency on phpunit/phpunit but we do have a dependency on phpunit/phpcov, what will happen? :-)

There's also this: https://github.com/symfony/symfony/issues/31948

@Mile23 so maybe use simpletest as wrapper to phpunit?

I guess I'm generally -1 on using simple-phpunit, for a few reasons:

• simple-phpunit is Symfony's run-tests.sh. Now we'll have two of them. :-)
• We don't need PHPUnit 4 any more for 8.8.x, so we can remove all the BC stuff and normalize on 6.5 for now, and make a plan to move on to 7+ as we get closer to Drupal core releases that don't support PHP 7.0. This script won't make that process any easier despite adding complexity.
• If we shell out to it from run-tests.sh (instead of phpunit), it will go through a composer -> update phpunit phase for every single test class. This is mitigated a little bit by having the new phpunit installed after the first go-through, but it still has to do it.
• We won't have a local PHPUnit in vendor, so your IDE won't autocomplete while you're writing tests.
• They might deprecate the script: https://github.com/symfony/symfony/issues/31948

If we definitely need to update PHPUnit to a later version during testing, then we could do that in run-tests.sh. Basically instead of telling you to do it as with the old drupal-phpunit-upgrade script, it would just do it based on a version matrix we can define in the script. That way we can do it once, and then run the tests.

And avoid adding more things named 'simple.' :-)

Since this was 3 years ago and I imagine there have been many changes for phpunit since then. Is this still needed? and if so what should be done.

Following up if this is still a valid task?