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

Feature Request: Add first-class support for PHPUnit #365

Open
4 of 5 tasks
aaemnnosttv opened this issue Jul 9, 2018 · 15 comments · May be fixed by #366
Open
4 of 5 tasks

Feature Request: Add first-class support for PHPUnit #365

aaemnnosttv opened this issue Jul 9, 2018 · 15 comments · May be fixed by #366

Comments

@aaemnnosttv
Copy link
Contributor

Submit a feature request or bug report


Feature Request

Installing, configuring, and running the WordPress core PHPUnit library has always been a pain. This creates an unnecessary barrier for WordPress developers to embrace testing, which is undoubtedly a core component of writing modern web applications.

I've been working on the best way to make the WordPress core PHPUnit library installable via Composer for a while now, and I'm happy to say that it is now just as easy to install as a vanilla Composer package.

I would like to propose the addition of WP PHPUnit to Bedrock's development dependencies, along with the necessary boilerplate for everything else PHPUnit needs to run - including CI configuration. Once Composer dependencies have been installed, and the database created, PHPUnit can be run with a single command out-of-the-box.

I would liken the end goal to be similar to what is part of a fresh installation of Laravel. Structure, dependencies, and a working example test.

Unit tests are not just for plugins/themes. Applications like those built on Bedrock will likely have code which is specific to the application, or not structured as a plugin or theme which should still be tested. Not only that, but testing that your code works as expected in conjunction with all the other dependencies that your application requires is arguably more important than testing that a specific component of it works in isolation.

WP PHPUnit is extremely minimal and is very easy to use compared to the current workflow. It's also fully automated in its maintenance, and completely open-source.

You can see a full working example here: https://github.com/wp-phpunit/example-project
Although this isn't based on Bedrock, the setup is even simpler with Bedrock 😄

If added, WP PHPUnit could be easily removed if undesired without requiring any kind of complicated uninstallation procedure, similar to other components of Bedrock. I think I've made the case that its value as an easily opt-out-able component outweighs the cost one would incur if it were opt-in instead.

Is this something that the team would be receptive to considering a PR for?

Related #106

@swalkinshaw
Copy link
Member

I'd definitely be interested in this depending on the implementation. Tests are good 👍

If a PR isn't too much trouble, then it would be nice to see and try it out.

@aaemnnosttv
Copy link
Contributor Author

Great! I'll start putting together a PR for this very soon then.

@aaemnnosttv aaemnnosttv linked a pull request Jul 10, 2018 that will close this issue
@eshimischi
Copy link

Anything here?

@austinpray
Copy link
Contributor

austinpray commented Aug 11, 2018

#366

I’m gonna try to help get this going next week

@koconder
Copy link

koconder commented Feb 1, 2019

Happy to help guys, can also cook in native PHPCS and PHPUnit configuration for Travis CI and codecoverage reporting. Have a look at my repo: https://github.com/koconder/wordpress-test-template and a plugin you can see the Travis CI setup on: https://github.com/koconder/wordpress-test-template Shout if you need me to jump in and build out a PR on-top of any unit tests.

@chrillep
Copy link

+1 testing really should be a opt-out.

@mklepaczewski
Copy link

Can we help somehow to push this forward?

@swalkinshaw
Copy link
Member

#366 was a very good start and it just got stale. @aaemnnosttv are you still interested in reviving that if we provide more support/feedback? If not, someone else can start a new PR based on that one.

Looks like the most contentious part of #366 was the usage of wp-phpunit, so a simpler integration to start with would be most of #366 but just without that.

@mklepaczewski
Copy link

For what it's worth, I managed to import changes from #366 with slight modifications (mostly to config files, due to shifting from define to Config::define) and I can confirm that it still works.

This integration doesn't have to be as simple as composer install. Importing non-contentious changes from #366 and adding # Testing section in readme.md would go a long way.

@swalkinshaw
Copy link
Member

@mklepaczewski do you want to put up a new PR with those minimal changes?

@mklepaczewski
Copy link

mklepaczewski commented May 10, 2021

Sure, I'll try to prep it within few days. There's not mucg to do there, I'm just quite busy.

@vilanle
Copy link

vilanle commented Aug 5, 2021

Hello! Any lead on this addition or a working example from @mklepaczewski ? Really interested in adding to my bedrock wp setup!

@chrillep
Copy link

Needs more LOVE ❤️. Testing FTW 🥰

@mklepaczewski
Copy link

If I said I'll do it then I'll do it, I don't need to be reminded about it every two years.... ;-)

On a more serious note, I scheduled it for the 8th of July.

@mklepaczewski
Copy link

Update: I imported changes from #366 into a new branch (it's not released yet) and did some tests. For the most part, it works, but I want to inspect one quirk before I push it. I'm out of time for the task, so it has been rescheduled for July 15th.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants