Description
Submit a feature request or bug report
- I've read the guidelines for Contributing to Roots Projects
- This is a feature request
- This is a bug report
- This request isn't a duplicate of an existing issue
- I've read the docs and followed them (if applicable)
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