Recent searches
Search options
Is there a way to disable or hide the #PHPUnit deprecations? I have 265 of them for data providers that aren’t static, and I can’t easily switch to static data providers, since many of the data providers call instance methods (i.e., `$this`). So, it’s going to take me a long time to upgrade my tests so that I can upgrade to PHPUnit 10.
Ugh. I wasn’t looking at all the test suites. So, there are 460 data providers that need to be converted to static.
@ramsey I'd be pretty sure that there's a rector that can do that for you
@MarkBaker And it’ll probably change all my other code at the same time, too. 
@ramsey @MarkBaker nope it won't, but if your providers need logic modification (if they call other non-static methods) it won't be enough.
@alessandrolai @MarkBaker Ours require calling other methods on the instance, which Rector can’t help with. I’m doing lots of `new static(static::class)` to access them. 
@ramsey But those methods could be static as well, couldn't they?
And isn't that perhaps calling too much logic for a data-provider? 
I took the move to PHPUnit 10 also to rethink some of that data-provider logic and clean out some tests as well. But that is nothing that works en passant....
@heiglandreas @ramsey @MarkBaker that's exactly what Sebastian wants to push us to do with this deprecation: instance logic in providers may have unintended effects, because they get executed very early in PHPUnit's lifecycle..
IIRC this will allow PHPUnit 11 (or further) to execute data providers on demand, like generators.
@alessandrolai Yeah! Stumbled over that some time ago when step-debugging a test that data providers are executed no where near the actual test...
So having logic in them interesting things can happen
/cc @ramsey @MarkBaker
@heiglandreas @alessandrolai @MarkBaker I don’t have a problem with the decision to make them static, other than the fact that I have 460 data providers that need to be modified, along with whatever else they call and depend on.
@ramsey @heiglandreas @alessandrolai @MarkBaker Isn't that what interns are for? 
@ramsey data providers for tests have to be static functions for phpunit 10?
Not a good news for me too! 
@derickr These aren’t E_USER_DEPRECATED or E_DEPRECATED messages. These are messages coming from PHPUnit about portions of it’s own API that are deprecated, and they’re not using E_USER_DEPRECATED or E_DEPRECATED.
@ramsey @derickr Ha, you've found my pet peeve! I do want my tests to fail on PHP deprecations, I don't want my tests to fail on PHPUnit deprecations.
PHPUnit 10 does not allow for that anymore....
I still need to write this up properly at some point and open an issue as this is inane.
Also see: https://github.com/Yoast/PHPUnit-Polyfills/issues/134
@ramsey you can exclude paths
@GuillaumeRossolini I want the tests to run.
@ramsey yes that’s what it does, run the tests but ignore the errors? At least with the config file it can be done. The files themselves can’t be ignored
@GuillaumeRossolini If I exclude paths in phpunit.xml, the tests in those paths are not executed.