[PHPUnit 10] @dataProvider methods must be declared static and public

Hmm, I get 1124 (hopefully) relevant results for @dataProvider.

How to scope such a thing?

Are we OK with one big patch/MR that should pass with no deprecation errors as mentioned in the IS, using a tweaked composer so it will use PHPUnit 10.x? It is a straightforward replacement IMHO.

I think we should change without composer tweak. It should work now on PHPUnit 9.5 with public static; it will be just ready for the future.

Ah, I seemed to make myself not clear enough (per usual...)

I meant it should work now/on PHPUnit 9.5, but using PHPUnit 10.x in a "should_not_fail"-patch just to confirm we've got them all.

Anyway: Indeed beta-release window springs to mind :)

Re #4/#5 if this can be done with a bulk find-and-replace or similar script (so it can be easily rerolled) then it can be committed in one go in a beta window - bonus points for providing the script so others can reroll it on demand.

If some data providers require separate refactoring (e.g. because they call non-static methods) then it might be best to split those out to a separate issue so they can be handled first.

To fix all this Undefined variable: $this because we're now in static-land, we _could_ do something like:

Pre:

  public function nonHtmlResponseProvider() {
    return [
[SNIP] 
      'A dummy that implements AttachmentsInterface' => [get_class($this->prophesize(AttachmentsInterface::class)->reveal())],
    ];
  }

Post:

  public function nonHtmlResponseProvider() {
    return [
[SNIP] 
      'A dummy that implements AttachmentsInterface' => [get_class((new BigPipeResponseAttachmentsProcessorTest())->prophesize(AttachmentsInterface::class)->reveal())],
    ];
  }

which does pass PHPStan checks.

Would that be the way to go here?

All clear, thanks @mondrake.
(Also booh! to Yet Again no pot-o-gold at the end of the rainbow)

So didn't look at all 674 files but skimmed a very good chunk of them and they all appear to be doing what the ticket/script describes and adding static to provider functions in tests.

Did verify only test files appear to be touched, tests are green.

Is there a way to prevent commiting new code with non-static methods?

Thank you for elaboration! Sounds like solid plan, maybe rector's rule to have predictable conversion would be great addition)

I was about to commit this and was scanning the diff for the last time when I had a thought: should we add array return types to each of these methods while we are here? Some already have return types, but most do not, and as we are changing the method signature already...

If you disagree and think this is out of scope and we should do it separately, please set it back to RTBC.

OK, the fact that data providers do not always return array convinced me that this is not the right place to be doing this, and we should handle it all in one go later.

Usually we would also handle this sort of bulk change in the beta phase, but as discussed in Slack it is better to land this now so we can clear the noise and figure out how to solve the issues with the remaining data providers. We should also commit this now before 10.3.x and 11.x diverge, this might become harder once we have other 11.x only changes.

Committed 654b1f2 and pushed to 11.x. Thanks!

Shouldn't this get a change record? Also to inform contrib modules extending core tests how they can do this in a way that does not break BC with 10.2.x and earlier?

Something like:

Core did:

-  public function urlProvider(): array {
+  public static function urlProvider(): array {

To make your contrib module extending this test compatible with >=10.3, make a matching change. But to retain compatibility with <=10.2, also add:

public function urlProvider(): array {
  return self::urlProvider();
}

Data providers can already be static, there is no need to add backward compatibility - we did nothing here to core except add static to method declarations, and everything still works on PHPUnit 9.

Added https://www.drupal.org/node/3421393 - we can expand with more examples of how to refactor the more complex cases once we have figured that out ourselves.