Deprecate TestDiscovery test file scanning, use PHPUnit API instead

We are hitting a PHPUnit bug here, The file attribute of node of XML test list can be wrong. So we still need to read the file of a test class from the classloader.

I think we can still avoid the classloader. On it.

Very interesting side effect of this - since PHPUnit discovery actually executes the dataproviders, and includes in the discovery list as many test cases as the number of datasets provided for a test method, we can now be precise in the number of test cases run for each test class, and use that information in run-tests.sh instead of the current approximate count.

I was thinking in a follow up we could introduce a “weight“ to #slow (i.e. #slow300, #slow200, etc) and further tune the start sequence.

We can leverage on PHPUnit API also to determine the test description, instead of doing separate parsing. On it.

Done #14.

Filed #3504223: Introduce a “weight“ to #slow tests re #12 and #13.

merged with HEAD after commit of #3497327: Extend PhpUnitTestDiscoveryTest to test also PHPUnit API

Thanks for review @mstrelan, added some of your suggestions and replied inline to some other ones; NW to address the remaining comments.

Postponed on #3521815: Fix test annotations for tests introduced by #3485896

Found some issues while testing this in combination with #3418267: Support PHPUnit 11 in Drupal 11. Given that one is RTBC, let's postpone on that.

Rebased. Since when this was RTBC last reviewed, added logic for determining group metadata information under PHPUnit 11.

edit - sorry, this was not RTBCed yet

Thanks for reviews!

I'd love to add @phpstan-type, but I am reluctant because of #3082239: Forbid limited length primary and unique keys, allow only in indexes and #3376270: Support PHPStan's annotations for local type aliases and array shapes.

removed duplicate @group #slow annotations

Made some updates to the CR to provide some input how to convert tests from annotation to attributes. Would be lovely to get a review there too.

Only merged with head, now tests are green. There's fortuity in randomness of test failures.

Can't figure out what would be impacting pipelines here - the MR one after revert and rebase seems to work fine. Pipeline config is not touched apart from the addition of a parameter when calling run-tests.sh.

Do we need publishing the CR?

Filed #3526499: PhpUnitApiGetTestClassesTest and PhpUnitApiFindAllClassFilesTest need to execute PHPUnit discovery before TestDiscovery after finding an issue while working on the followup conversions from annotations to attributes.

In next iteration, I would consider doing:

1) Bump PHPUnit to 11 in the lock file, instead of keeping it locked to 10. #3418267: Support PHPUnit 11 in Drupal 11 has been in for 3 weeks now and AFAICS no issue have been reported about that. PHPUnit 11 also support PHP 8.3, which is minimum for D11. We can still keep 10 in the composer.json in case anyone has the need to downgrade for incompatibility (which, again, was not found yet).

2) Include #3526499: PhpUnitApiGetTestClassesTest and PhpUnitApiFindAllClassFilesTest need to execute PHPUnit discovery before TestDiscovery which was meant to be a followup of this, but since now it’s open again, better do straight ahead.

Then, if #3526778: Tests not running or failing when using run-tests.sh in 11.2.0-dev willl still not be resolved, it should be (theoretically) only a matter of listing the relevant directories in phpunit.xml.dist - and that would require another core fix if contrib is meant to run with core configuration.

I’d also suggest to commit initially only to 11.x to allow proper checking in gitlab templates, and only eventually backport to 11.2.x upon complete validation.

I do not understand why the CSpell job fail given that the file reported is included in the ignored paths in .cspell.json.

Then waiting for feedback to question in #3527063-8: Update for changes required by D11.2 to see if we do need to edit the <directory> sections of phpunit.xml.dist to accomodate contrib testing.

Solved the CSpell problem.

Done #58.

Apparently the syntax to pick the test files in the /module subdirectory was failing somehow, changed after some thorough manual testing documented in https://drupal.slack.com/archives/CGKLP028K/p1748635336355999

This should hopefully fix the issue in #3527063: Update for changes required by D11.2 with no changes to need happen there (once this is back in).

@ghost of drupal past sorry I do not understand your question. Can you please elaborate?

Image Effects seems to work fine Test with 11.2.0-rc2

Project Browser seems to work too Test with 11.2.0-rc2

Updated release note snippet.

The new code can manage both @group annotations and #[Group] attributes, otherwise 99% of core would be failing. So contrib is not requested to add the attribute. The linked tests in #72 and #73 prove it anyway.

So it must be something else, looking.

The error is

Drupal\Core\Test\Exception\MissingGroupException: Missing group metadata in test class Drupal\Tests\Composer\Generator\BuilderTest in /builds/project/scheduler/web/core/lib/Drupal/Core/Test/PhpUnitTestDiscovery.php:304

which is very very strange as that test (which is a core test btw) clearly DOES have a @group Metapackage annotation and it runs no problem in core.

Gut feeling is that the contrib is playing with the pwd of the job and PHPUnit/autoloading cannot find the class.

I am looking into this. Knowing the inners, it's very strange as that exception is thrown after the test list has been already built by PHPUnit, which is common with the other two tests.

Image Effects runs tests with pwd = /builds/project/image_effects
Project Browser runs tests with pwd = /builds/issue/project_browser-3530110

Opened #3530183: Test Scheduler at 11.2.x-dev with patched PhpUnitTestDiscovery.php in Scheduler's module issue queue to try and understand what's going on.

#3530183: Test Scheduler at 11.2.x-dev with patched PhpUnitTestDiscovery.php has a debug patch for core that now makes tests pass. Most important would now be to understand why PHPUnit sometimes does not pass a filled in Test object; then we can make a core patch.

Do I need to open a separate issue or an additional MR in this issue, eventually?

Filed #3530202: Introduce PHPUNIT_FAIL_ON_PHPUNIT_DEPRECATION in GitLab Templates issue queue.

We might have surfaced a bug upstream (PHPUnit's test suites builder seems to be adding empty TestSuite sub-objects to the main TestSuite object under some unclear circumstances), but this minimal MR!12382 fix seems to let the overall testing discovery complete in that case. #3530183: Test Scheduler at 11.2.x-dev with patched PhpUnitTestDiscovery.php is now passing with the equivalent of the MR as a patch.

Will try to see if I can report upstream, but that will require quite some investigation before being able to - building a self-contained minimal patch reproducing the issue is not going to be a simple one.

Copy/pasting here more details I added in #3530183-8: Test Scheduler at 11.2.x-dev with patched PhpUnitTestDiscovery.php.

I could replicate the issue in Image Effects https://git.drupalcode.org/project/image_effects/-/merge_requests/72 by choosing to select tests by group instead of by directory.

To me the issue is a bug upstream: PHPUnit 'builds' the list of tests to execute as a hierarchical structure of TestSuite and TestCase objects, and seems to be adding empty TestSuite sub-objects to the main TestSuite object under some unclear circumstances.

Core patch developed here seems to work, and it is now a follow-up MR in core's #3497431-88: Deprecate TestDiscovery test file scanning, use PHPUnit API instead.

It just skips, though, empty TestSuite objects which may lead to skipped test runs if the @group/#[Group] of the test class skipped corresponds to the group filter when running runt-tests.sh. I will keep investigating in Image Effects issue #3530105: Test with 11.2.0-rc2.

I think core's #3530113: Allow indicating alternative phpunit.xml than core's when testing via run-tests.sh would help as it could open up the possibility to declare the directories to be searched for test discovery by the module, if run-tests.sh execution is filtered by test group. This will prevent discovering all of the core test files as it is happening now.

So as detailed in #3530183-13: Test Scheduler at 11.2.x-dev with patched PhpUnitTestDiscovery.php, the issue reported in #76 is due to gaps present elsewhere, that the PHPUnit discovery process legitimately cannot deal with.

In the MR, now, an implementation of PHPUnit's Tracer is collecting warnings thrown by PHPUnit during discovery, and reporting them in the run-tests.sh output so they can be actioned. The discovery process is now completed instead of failing as it was identified in #76, but the actual list of tests to be executed will be missing those tests that errored during discovery.

I was on the verge of self-RTBC already, #91 confirms, so let's get going.

I'll work on a CR. Re #97:

But if they are skipped due to 3rd-party module problems then that will me we lose test coverage until they can be fixed.

to me this is not going to mean lost test coverage. We need to distinguish test discovery from test execution. Test discovery looks for ALL the test classes available (based on some pre-constraints sometimes, e.g. if you specifically indicate a directory to search in, it will be limited to that), then filters only those that need to be executed.

In the case of the wrong dataprovider in address and token modules of the related issue, these are reported as failing when building the test list during discovery, but are not executed because the filter is @group scheduler_xxx. So, the scheduler tests are not really affected. They would fail loud on tests executed on those modules with PHPUnit 11 (time to apply the static modifier...), or if, from the scheduler module, you'd run tests for @group token or @group address. But that's because the dataprovider must be static, not for the discovery.

Added CR https://www.drupal.org/node/3530388, appreciate review and publishing.

@jonathan1055 kindly reviewed the new CR, I published it. Tentatively marking this fixed as it looks to me there's nothing else to do.

There are a few issues already towards converting metadata from annotations to attributes, see related #3446380: [no-commit] Define a Rector rule to convert test annotations to attributes, #3446693: Convert test annotations to attributes in Drupal/Test/Component, #3526490: Convert test annotations to attributes in Drupal/BuildTests. But they are currently children of the original #3418267: Support PHPUnit 11 in Drupal 11. It would be probably be the case now to open a new meta for the conversions (there are 000s of files to convert), and reparent those to it.

When it comes to the deprecations, with PHPUnit 11 we need to distinguish between SUT deprecations and PHPUnit runner deprecations - the former are the 'traditional' ones, the latter are internal to PHPUnit. Core, when running tests through run-tests.sh, currently DISABLES PHPUnit runner deprecations by setting the env variable PHPUNIT_FAIL_ON_PHPUNIT_DEPRECATION to FALSE. This leads to SUT deprecations being reported but no PHPUnit ones. #3530202: Introduce PHPUNIT_FAIL_ON_PHPUNIT_DEPRECATION aims at introducing the same capability in GitLab Templates; contrib using run-tests.sh can anyway already use it if needed.

Re #105

Until we do that I don't think we can remove deprecated usages in the test themselves because they'd be needed for phpunit 10.

per se PHPUnit 10 can perfectly process attributes only, so if tests are run via PHPUnit CLI, no problem to have attributes only in contrib. See https://www.drupal.org/project/sophron for example. The problem is if tests are run via the run-tests.sh script BEFORE Drupal 11.2: in that case the 'old' TestDiscovery process is in place, and that one is not capable of dealing with test classes that lack the @group annotation.