PHPUnit 9 has a PHP version constraint of >=7.3 in its composer.json file and will receive regular bug fixes until February 4, 2022. On that day, PHPUnit 9 enters Life Support.
Life Support means that changes will be made for an otherwise unsupported version of PHPUnit to be compatible with new versions of PHP.
There is a technical limitation here with regard to how long into the future a version such as PHPUnit 9 can be made compatible with new versions of PHP: making an old version of PHPUnit compatible with a new version of PHP must not result in a backwards compatibility break of that old PHPUnit version.
For example, until recently, PHPUnit 8.5 had a class named Match. PHP 8.0 introduced a new keyword, match, and classes named Match are no longer allowed. Had PHPUnit 8.5's PHPUnit\Framework\MockObject\Builder\Match class not been annotated as @internal the change to make it compatible with PHP 8 would have broken backwards compatibility.
PHPUnit 8 has a PHP version constaint of ^7.2 in its composer.json file and will receive regular bug fixes until February 5, 2021. I am working on making PHPUnit 8 compatible with PHP 8 (see 312641dd7d7c78aad6d23dad74cb88774e1df6e6 and f758666a5649d64fd38b2983894e95a62740c6e4).
I have reached a point where I can run PHPUnit 8's own test suite successfully with PHP 8. But PHPUnit's code coverage functionality will not be available with PHPUnit 8.5 on PHP 8 (due to changes in php-code-coverage that are just not feasible to backport). I do not think, though, that this is a problem. If you want to upgrade your software and currently run your tests with PHPUnit 8 on PHP 7.2, PHP 7.3, or PHP 7.4 then "just running them" (without code coverage) on PHP 8.0 should be good enough to help you with your PHP upgrade.
The "only" thing missing for making PHPUnit 8.5's Life Support official is to change the PHP version constaint to >=7.2 in its composer.json file and in the composer.json files of all of its dependencies. This means that I need to go through all of these dependencies, see whether their tests run on PHP 8, and make compatibility changes where needed.
TL;DR: The goal here is to offer Life Support for PHPUnit 8.5.
doctrine/instantiator used by PHPUnit 8.5 is compatible with PHP 8myclabs/deep-copy used by PHPUnit 8.5 is compatible with PHP 8phar-io/manifest used by PHPUnit 8.5 is compatible with PHP 8phar-io/version used by PHPUnit 8.5 is compatible with PHP 8phpspec/prophecy used by PHPUnit 8.5 is compatible with PHP 8phpunit/php-code-coverage used by PHPUnit 8.5 can be installed on PHP 8 (it will not work on PHP 8, though)phpunit/php-file-iterator used by PHPUnit 8.5 is compatible with PHP 8phpunit/php-invoker used by PHPUnit 8.5 is compatible with PHP 8phpunit/php-text-template used by PHPUnit 8.5 is compatible with PHP 8phpunit/php-timer used by PHPUnit 8.5 is compatible with PHP 8phpunit/php-token-stream used by PHPUnit 8.5 can be installed on PHP 8 (it will not work on PHP 8, though)sebastian/code-unit-reverse-lookup used by PHPUnit 8.5 is compatible with PHP 8sebastian/comparator used by PHPUnit 8.5 is compatible with PHP 8sebastian/diff used by PHPUnit 8.5 is compatible with PHP 8sebastian/environment used by PHPUnit 8.5 is compatible with PHP 8sebastian/exporter used by PHPUnit 8.5 is compatible with PHP 8sebastian/global-state used by PHPUnit 8.5 is compatible with PHP 8sebastian/object-enumerator used by PHPUnit 8.5 is compatible with PHP 8sebastian/object-reflector used by PHPUnit 8.5 is compatible with PHP 8sebastian/recursion-context used by PHPUnit 8.5 is compatible with PHP 8sebastian/resource-operations used by PHPUnit 8.5 is compatible with PHP 8sebastian/type used by PHPUnit 8.5 is compatible with PHP 8sebastian/version used by PHPUnit 8.5 is compatible with PHP 8theseer/tokenizer used by PHPUnit 8.5 is compatible with PHP 8FYI, doctrine/instantiator is ^1.3.1 for phpunit 8.5, and that version is already php 8.0 compatible according to their composer.json
FYI,
doctrine/instantiatoris^1.3.1for phpunit 8.5, and that version is already php 8.0 compatible according to their composer.json
Thank you!
As of 73435f4bac40a63d18f04707858c738a64c1f7ed, PHPUnit 8.5 uses >=7.2 as the PHP version constraint in its composer.json file.
I do not know whether I should just tag the next PHPUnit 8.5 release and see what happens or whether I should wait until some of the people who would like for PHPUnit 8.5 to work on PHP 8 had a chance to give this a try. Thoughts?
I would also appreciate any insight as to why the tests for PHPUnit 8.5 currently fail for PHP 8 on Windows.
The erroring test cases all run in seperate processes, so my best bet would be that those are not working on widows for php 8.0 correctly.
All failures appear to be .phpt tests, which aren't giving any output.
Checking on Windows...
I do not know whether I should just tag the next PHPUnit 8.5 release and see what happens or whether I should wait until some of the people who would like for PHPUnit 8.5 to work on PHP 8 had a chance to give this a try. Thoughts?
For what it's worth: I've run the complete Symfony testsuite on my local PHP 8 set-up using PHPunit 8.5.x-dev and 9.0. There are no differences in the result (I believe my PHP 8 set-up is not correct, as there are quite some failures on both versions, but the failures are exactly the same on both versions).
I have released PHPUnit 8.5.12 which should be installable on PHP 8 and which should work on PHP 8 (minus code coverage, as explained above).
I can confirm @wouterj's observation.
Thank you so much for you work here, @sebastianbergmann!
Checking on Windows.
Thank you, Gaetano. If you find something then please open a new ticket. Thanks!
I think I isolated the problem with windows down to the way DefaultPhpProcess::runProcess() handles pipes.
Error message is Stderr: The filename, directory name, or volume label syntax is incorrect.
Will open a PR as soon as I have it working...
Maybe best to set it as ^7.2 || ^8.0 so that it won't install on php 9 in the future
Most helpful comment
I have released PHPUnit 8.5.12 which should be installable on PHP 8 and which should work on PHP 8 (minus code coverage, as explained above).