TestDiscovery expects @group annotations, fails with #[Group()] attributes

Tests need fixing, but I think the concept is reviewable.

Getting rid of custom code and just relying on PHPUnit to discover tests is a bit too far and actually PHPUnit itself only recently changed format for --list-tests-xml output, and modified test list filtering options, in PHPUnit 11.1. So better wait to be on that before trying it.

For now just extended TestDiscovery to look into attributes of test classes, falling back to annotations if they do not exist (like PHPUnit itself is doing).

Tests are green now.

Added draft CR.

FWIW, I am pretty close to have an alternative implementation using PHPStan's BetterReflection.

This would have the benefit of not loading all test classes via PHP's Reflection.

But two drawbacks:
1) it will be much slower
2) it would require, at least for now, 📌 Downgrade (temporarily) nikic/php-parser to ^4 Closed: won't fix

I do not think that's worth doing. In the future, I'd suggest to switch TestDiscovery to get the test list by executing PHPUnit's CLI with the --list-tests-xml option and parsing the resulting XML. That would effectively mean delegating 'how' test classes are discovered entirely to PHPUnit, in a separate process so that PHP's own allocated memory allocated would not be a constraint (if it is right now, today, I doubt anyway).

Just a question why new conflict added to composer?

"nikic/php-parser": ">=5"

MR!8054 uses PHP reflection.

MR!8125 implements #7, uses BetterReflection (static reflection, no class loading in memory), and requires downgrading nikic/php-parser to 4, for the reasons discussed in 📌 Downgrade (temporarily) nikic/php-parser to ^4 Closed: won't fix .

We need to decide on which horse to bet.

As I get https://github.com/Roave/BetterReflection/pull/1387 already fixed and BetterReflection should work with v5 too

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Can I ask, please, to get a review of the two options and guidance on which one (or others) to follow? Not very keen in keeeping two alternative approaches rebased just to keep the NR; the second option would require rebasing anytime a dependency is bumped.