Add test suite for Plugins folder

[mukeshpanchal27]

Summary

Fixes #934

NOTE: Checking test suite for plugins folder.

Relevant technical choices

Checklist

• PR has either [Focus] or Infrastructure label.
• PR has a [Type] label.
• PR has a milestone or the no milestone label.

[swissspidy]

> wp-env run tests-cli --env-cwd=/var/www/html/wp-content/plugins/$(basename $(pwd)) composer test -- --testsuite=webp-uploads

ℹ Starting 'composer test --testsuite=webp-uploads' on the tests-cli container. 

Soo... four dashes it is? 🤔 Unless wp-env has some weird logic for passing additional args.

$ npm run test-php -- -- -- --testsuite=webp-uploads

> test-php
> wp-env run tests-cli --env-cwd=/var/www/html/wp-content/plugins/$(basename $(pwd)) composer test -- -- --testsuite=webp-uploads

This should run composer test -- --testsuite=webp-uploads on the container, which would then run phpunit correctly.

[thelovekesh]

@mukeshpanchal27 @swissspidy I was wondering if we can avoid the wp-env based WP setup in CI and instead use SVN+Maridb to set up the test suite?

With wp-env:

• we can see increased CI times(on AMP we reduced it to 3-4 mins from 7-8 mins).
• API changes. The previous one was related to removing the PHPUnit containers.
• Maintenance issues in the case of the above scenario.

On the AMP plugin, we faced similar issues and we had to remove wp-env and switch back to the "vanilla" setup for multisite tests.

Recently I was working on a POC to improve the workflows for the Performance Lab plugin which can be found at - thelovekesh#2 and it uses bash-based tests setup.

Also, let me know if the above PR makes sense, and I will open it on this repo after testing.

[swissspidy]

I see your point and personally like not having to use wp-env on CI. There are pros and cons for each setup though. Probably best to open an issue for wider discussion.

[mukeshpanchal27]

@swissspidy, do we need to merge trunk into feature/modules-to-plugins to get the unit tests related changes in the branch, and then rebase this PR branch onto feature/modules-to-plugins? What do you think?

[swissspidy]

Seems like it 👍

[mukeshpanchal27]

@swissspidy, do we need to merge trunk into feature/modules-to-plugins to get the unit tests related changes in the branch, and then rebase this PR branch onto feature/modules-to-plugins? What do you think?

PR #959.

[mukeshpanchal27]

The PR currently indicates failures in certain workflows, even though these issues have already been addressed in the trunk. The changes from #968 will be incorporated, and once completed, the PR should function correctly.

[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.

Core SVN

If you're a Core Committer, use this list when committing to wordpress-develop in SVN:

Props: mukesh27, swissspidy, westonruter, thelovekesh, flixos90.

GitHub Merge commits

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: mukeshpanchal27 <mukesh27@git.wordpress.org>
Co-authored-by: swissspidy <swissspidy@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>
Co-authored-by: thelovekesh <thelovekesh@git.wordpress.org>
Co-authored-by: felixarntz <flixos90@git.wordpress.org>

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