Problem/Motivation
This issue is about allowing to optionally use PHPUnit ^7 to run tests in Drupal 8, while keeping support for PHPUnit ^6.5 .
- PHPUnit 6 is out of support since Feb 1, 2019. So we are already using an unsupported PHPUnit version in our testing ecosystem.
- PHPUnit has a very strict policy of releasing a new major in line with PHP releases, and supporting only current and current-1 major:
- PHPUnit 7 was released in early 2018 and will be supported until Feb 7, 2020
- PHPUnit 8 was released in Feb 2019 will be supported until Feb 5, 2021 - #3063887: Support PHPUnit 8 in Drupal 8
- PHPUnit 9 will be released Feb 2020.
The problem to solve to support PHPUnit 7 vis-à-vis PHPUnit 6 is that it changes the signature of a number of its methods and removes some that were deprecated earlier, making it impossible to extend its classes in a way that can work seamlessly between the 2 versions. In a pratical example, PHPUnit 6 declares PHPUnit\TextUI\ResultPrinter::printResult like
public function printResult(TestResult $result);
whereas PHPUnit 7 like
public function printResult(TestResult $result): void;
so you cannot extend for example from ResultPrinter and override a method in a unique way, because in one of the versions PHP will step in and throw a fatal error for the different type hinting.
Several classes and methods in the current test codebase are extending and overriding directly from PHPUnit classes and are subject to this issue - listeners, asserts, etc.
Proposed resolution
Create a bridge between PHPUnit and the test codebase, that making use of class_alias loads classes and traits depending on the PHPUnit runner version. These classes/traits adhere to the runner version required type hinting, and are conveniently grouped in namespaces organized by runner version - for PHPUnit6 and PHPUnit7 here. This allows to (a) easily drop support for a PHPUnit version by removing all the classes of a PHPUnitX bridge and upping the composer constraint, and (b) add support for future PHPUnit versions by adding PHPUnit8, PHPUnit9 and so forth bridges - when time comes.
AFAICT, the concept is generally BC, as it allows to run the tests on both PHPUnit 6 and on PHPUnit 7 with a single test codebase, as latest patches show. Contrib might need to adjust some assertions, though, or tests that depend on the internals of PHPUnit.
It would not be necessary to force the composer.lock to be updated. We can just loosen the composer.json constraint to allow PHPUnit 7 to be installed, similiarly to the approach that is being taken, AFAICS, for #2976394: Allow Symfony 4.4 to be installed in Drupal 8. Then hi/lo dependencies testing will ensure running on both versions.
Remaining tasks
review
User interface changes
none
API changes
none
Data model changes
none
Release notes snippet
tbd
Original report:
I know that the testing infrastructure just switched to phpunit 6.5 two month ago but in the meantime PHPUnit 7 was released.
so the deadline to switch, and some important dates
- PHPUnit 6 support ends on February 1, 2019 https://phpunit.de/
- PHPUnit 6 does not support PHP 7.3 which is planned to be released late 2018 http://php.net/supported-versions.php
- with Drupal 8.7 March 6, 2019 we can stop using PHPUnit 4 as only PHP7 will be supported by Drupal https://www.drupal.org/node/2938726
so the deadline is like ~8 months from now based on PHP 7.3 release.
can PHPUnit 7 be used from now?
- the problem might be PHP 7.0 as it is not supported by PHPUnit 7
- PHP 7.0 will be EOL 3 Dec 2018 http://php.net/supported-versions.php
so it seems 2018 Nov-Dec is the date to switch..
.. or start using 3 different versions of phpunit now:
PHP 5.5; 5.6 > PHPUnit 4 (4.8)
PHP 7.0 > PHPUnit 6 (6.5)
PHP 7.1; 7.2; 7.3 > PHPUnit 7