Simplify PHPUnit setup

[swissspidy]

I have troubles running the unit tests if the plugin-check folder isn't within wp-content/plugins of an actual WordPress installation. I don't want to change my setup because of this.

1. Remove separate build-phpunit folder.
   • We added this in the past because of different PHP version requirements.
   • Now that we require PHP 7.2+, this is no longer needed and we can simplify our testing setup.
2. Remove plugin validation in Force_Single_Plugin_Preparation
   • Runtime check unit tests call this with the basename of the Plugin Check plugin
   • In my setup, I check out the plugin-check repository somewhere else on the computer, not within a WordPress installation.
   • Because of this, the validation would fail all my tests because the plugin couldn't be found
   • I don't see a strong need for this validation
   • Outright removing it is simpler than some additional logic to make this scenario work

With these changes I can now easily run tests locally using WP_TESTS_DIR=/path/to/wordpress-develop/tests/phpunit composer test

There are still some errors and failures, particularly in Plugin_Context_Tests and Check_Context_Tests, because of plugin path differences.

[swissspidy]

Interesting test failures right now 🤔

[swissspidy]

There are still 2 failing tests, but I think now's a good time to get a second pair of eyes

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: swissspidy <[email protected]>
Co-authored-by: felixarntz <[email protected]>
Co-authored-by: ernilambar <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[felixarntz]

@swissspidy Mostly LGTM, just one change that I don't think we should be making, at least not unconditionally.

[felixarntz]

This is not great, as it would be loading the plugin too late.

What problem exactly does it solve? If it's needed for a specific setup, we should make it conditional only if the more appropriate approach (directly filtering active_plugins option) does not work. That way, if this ever leads to a problem, at least it wouldn't affect the overall tests infrastructure for everyone.

[swissspidy]

IIRC I changed it mainly because this is the common way to set up plugin tests. But reverting that change actually seems to address the remaining two failures, so that's nice :)

[felixarntz]

because this is the common way to set up plugin tests

Curious where you get it from - I've never seen it :)

[swissspidy]

Any project that uses wp scaffold or a derivation of that setup, see https://github.com/wp-cli/scaffold-command/blob/036c5152f85861bbd46ec63b36cde9074d786117/templates/plugin-bootstrap.mustache#L28-L35

[felixarntz]

Hmm, FWIW I think this should be fixed there as it leads to problems - evidenced by this PR.

I don't see any reason not to filter the plugin option, this is something the WordPress test suite specifically allows for this kind of purpose with the wp_tests_options global.

[swissspidy]

Normally plugins wait until plugins_loaded to run code, so I'd say PCP is the exception here :-) But feel free to open an issue there

[felixarntz]

I just looked at the code, but it's using muplugins_loaded - so this is different from what you had changed it to here.

Using muplugins_loaded is okay, because that still loads the plugin early enough - even earlier than would be normal. But that's better than too late because everything that a plugin could do would still work.

I still think filtering active_plugins is the even better solution, but since it's using muplugins_loaded, that's fine. I was thrown off only because here the code was using plugins_loaded.

[JJJ]

If it needs to be as early as possible, how about a new dedicated drop-in plugin file in WordPress core itself?

(Sorry if I've mentioned this idea elsewhere. Having deja vu!)

[felixarntz]

@swissspidy LGTM, just one possible oversight.