Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI: (Re-)enable a test run against PHP 8.1/nightly. #659

Closed
jrfnl opened this issue Apr 15, 2021 · 1 comment
Closed

CI: (Re-)enable a test run against PHP 8.1/nightly. #659

jrfnl opened this issue Apr 15, 2021 · 1 comment

Comments

@jrfnl
Copy link
Collaborator

jrfnl commented Apr 15, 2021

Follow up action after #628

Conversation about this between @GaryJones and @jrfnl from #628:

(Re-)enable a test run against PHP 8.1/nightly.

Yes, but not urgent.

Agreed. I'm thinking we should leave this till the summer (2021) when a) there will be an PHP 8.1 alpha/beta to test with locally and b) it will become clearer what PHPUnit versions will support PHP 8.1.

That is, unless a simple, working solution presents itself in the mean time.

One thing I've been thinking about, which is related to this, is to:

  • either refactor the PHPCS unit test base in PHPCS 3.x to support a wider range of PHPUnit versions, but I'm not sure Greg would be open to this.
  • or to provide an abstract base test class via PHPCSUtils which would work cross-version PHPUnit and would only require the use statement to be adjusted for external standards to switch over to it.

That last solution would also get rid of the hassle of having to use the GH source for testing against PHPCS 4.x, which no longer includes the test base classes in the distribution zip.
The only real difference would be that it may not include support for adding the 46 sniff test files generated 190 unique error codes; 0 were fixable (0%) line at the bottom of the test run.

Via that last solution, I would also want to offer more extended test abilities, like:

  • testing that the correct error code is thrown where expected, so a change in a sniff changing the error code being thrown for a particular code snippet won't be "invisible" anymore from a testing perspective.
    Case in point - a change in PR IncludingFile: Add custom keywords to detect to reduce false positives #626 is doing exactly that and I caught it in the review, but it would have been easy to overlook.
  • and testing (for select test cases), that the error message is as expected. This is particularly interesting for sniffs which do things with code snippets in the error message where we'd want to guard that functionality.
    Example: the WordPress.PHP.NoSilencedErrors sniff.
@jrfnl
Copy link
Collaborator Author

jrfnl commented Aug 23, 2023

Closing. This looks to have been fixed via commit b6a26d7 in PR #705.

@jrfnl jrfnl closed this as completed Aug 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant