Support PHPUnit 10

[stof]

this is a meta-issue tracking blockers for using PHPUnit 10:

• Migrate to static data-providers #63
• [PHPUnit bridge] Support for PHPUnit 11.1+ symfony/symfony#49069 to support PHPUnit 10 in symfony/phpunit-bridge (that we rely on to report deprecations)
• PHPUnit 10 support? Yoast/PHPUnit-Polyfills#82 to support PHPUnit 10 in yoast/phpunit-polyfills (at least marking it as compatible in the composer constraint)
• Remove usage of onNotSuccessfulTest to mark tests as skipped #65 Removing usage of TestCase::onNotSuccessfulTest to mark tests as skipped as this is not supported anymore
• Making our base TestCase compatible with PHPUnit 10 (TestCase::getName was removed, replacing it with 2 methods instead of having a boolean flag)

[uuf6429]

Regarding the last point, to be clear: getName() got renamed to name() (not removed). I didn't get what was meant with two methods instead of flag, though. If that can be clarified, someone could maybe implement that change already.

[stof]

Well, the last point is not the hard block. Migrating to the new method will be easy. But it is not high priority as long as the other points are not resolved.

[uuf6429]

I'll consider jumping into some of those tasks.

On a totally unrelated sidenote, there are plenty of finished things ready to be merged (some of which are blocking the classic-webdriver) - what's the situation in general? Is it ok to merge my own PR given review approval?

[aik099]

symfony/symfony#49069 to support PHPUnit 10 in symfony/phpunit-bridge (that we rely on to report deprecations)

@stof , The issue was merged. Maybe we can proceed with PHPUnit 10 support now?

[stof]

To be exact, Symfony has decided to use the native deprecation handling features of PHPUnit 11+ (skipping PHPUnit 10 because the deprecation handling it had was not yet feature-equivalent). The bridge has not been reimplemented to support PHPUnit 10+ with the same user-facing API than older versions (which was not possible anyway due to the changes in PHPUnit).

However, it won't be possible to have the same phpunit.xml file for configuring support for PHPUnit 8 or 9.5 with the bridge on one side and PHPUnit 11 (without the bridge as the only feature we use in the bridge is the deprecation reporting) on the other side. Shipping phpunit config files with non-default names and forcing to use phpunit -c ... to use the right one would be a pain for contributors (and maybe also for keeping the CI setup understandable). So it would be better to keep only one family of PHPUnit versions.
Migrating fully to PHPUnit 11 requires bumping the min PHP version to PHP 8.2, which needs a discussion on the main Mink repo first (we cannot release a version of Mink advocating support for PHP 8.1 if our CI does not test it. That's the worse situation for sure).

[aik099]

Since the older PHPUnit versions don't work on newer PHP versions and vice versa I had to support all PHPUnit versions and due to radical phpunit.xml format changes in each upcoming PHPUnit version on my projects I was forced to have different PHPUnit configs just to make the build pass. The build file looks like this: https://github.com/console-helpers/svn-buddy/blob/master/.github/workflows/main.yml (note the phpunit_config matrix variable and its usage).

P.S.
Since PHPUnit 10+ any inconsistency in the phpunit.xml file (e.g. a key present to support older PHPUnit version) fails the build because PHPUnit returns a non-zero exit code.

[stof]

PHPunit 9.6 works on newer PHP versions. That's exactly what "Life support" means in PHPUnit.

[aik099]

PHPunit 9.6 works on newer PHP versions. That's exactly what "Life support" means in PHPUnit.

Ha-ha. Although PHPUnit does strictly follow SemVer: in major releases BC breaks will occur 😞 .

Without the https://github.com/Yoast/PHPUnit-Polyfills library (I guess the author has similar issues with supporting non-maintained PHP version) it would be painfully hard to have a test suite that will work on every PHPUnit version.

Multiple phpunit.xml usage during the build is a small price to pay to avoid doing IFs all over test suite for supporting different PHPUnit versions, that tend to drop/rename assertion methods quite frequently.

[stof]

Well, you used as argument "Since the older PHPUnit versions don't work on newer PHP versions and vice versa". but that argument is wrong.

[aik099]

Well, you used as argument "Since the older PHPUnit versions don't work on newer PHP versions and vice versa". but that argument is wrong.

@stof, sorry for the confusion.

Yes, older PHPUnit versions probably work on newer PHP versions. What I've mean is that if I want to use a newer PHPUnit version, then I'm forced to use a newer PHP version as well.

This is what I'm concerned about. So if a developer wants to use a newer PHPUnit version, but upgrading the project codebase to a new PHP version isn't possible, then they can't use PHPUnit version as well.

[stof]

"A developer" here being a concern only for "Mink driver maintainers".
And I think it is much easier for the Mink maintainers to pick a version of PHPUnit supporting all the target PHP versions rather than supporting multiple major versions of PHPUnit that are hard to support at the same time (especially given that this still won't allow using newer PHPUnit features, as you need to keep compat with the old version)