This goes with my talk “JavaScript Testing In And Around WordPress.” It’s a two part talk, first about testing React apps. The second part gives applies those topics to WordPress plugins that add blocks to the WordPress block-based editor.
I’m really geeked about this talk. Testing JavaScript apps is really important. Also, a lot of fun. I also think that this next phase in WordPress development — a move to React-powered UIs that are often decoupled from WordPress is great — but requires a serious commitment to automated testing or we will not be able to meet the needs of people visiting our sites or those building them.
A key benefit of developing blocks loosely coupled to WordPress is you can reuse the components anywhere. This is great – you spend less time developing duplicate functionality, and a more consistent user experience. The downside is if any component becomes buggy or defective it affects every client consuming it. That’s a big risk and if you’re not developing the component in every single context it’s used, then the bug or defect may not be obvious.
– Me, in a recent guest post for Pantheon that I don’t want to just repeat the same arguments from in this post. But, TL;DR – resuse is good, as long as the component works everywhere, which we can prove, with tests.
Using WordPress Scripts For WordPress Block Development
I want to highlight one part of my talk, which covers the WordPress Scripts package – @wordpress/scripts. This is a zero-config build and testing tool for WordPress development. It works on top of Jest, Babel, webpack and other tools you need for modern JavaScript development.
This is the easiest way to configure Babel and webpack for WordPress development. It’s like create-react-app for WordPress.
How To Add WordPress Scripts To Your Plugins
This is a quick guide, the slides and the README, have way more information.
First, install:
yarn add @wordpress/scriptsUpdate package.json –
{
"scripts": {
"build": "wp-scripts build",
"check-engines": "wp-scripts check-engines",
"check-licenses": "wp-scripts check-licenses",
"lint:css": "wp-scripts lint-style",
"lint:js": "wp-scripts lint-js",
"lint:pkg-json": "wp-scripts lint-pkg-json",
"start": "wp-scripts start",
"test:e2e": "wp-scripts test-e2e",
"test:unit": "wp-scripts test-unit-js"
}
}
Then create a Gutenberg block at /src/index.js. You can compile it to build/index.min.js like so:
yarn buildOr do many other things, such as testing. Which I cover a lot in this talk 🙂
You can see a complete example of how this all works in this example code plugin I put on Github for this talk. Also, so I can use it as a template for when I have to make a plugin.
How To Use WordPress e2e Testing Tools
This plugin and the talk cover automated browser testing with the WordPress end to end testing tools. This could have been its own talk. I did want to have a complete example of how to set up the local development environment and configure Jest for these tests.
Slides And Links
Example Code
BTW I Used MDX-Deck, It Is Good.
This is an off-topic aside about making the slide deck. Because, Josh.
I normally use Google slides. I’m never happy with how code looks, if its pasted in as text. With a lot of effort, I’ve gotten it to look good with screenshots. That makes the code invisible to users who do not load images and you can’t cut and paste the code from the deck.
Anyway, I started thinking about how I wished I could just write it in markdown. MDX mixes React JSX and markdown. It’s really ideal for writing about code and mdx-deck wraps it up in a slide presentation. Very cool.
Best part is, I wrote it in vsCode. The syntax highlighting and automatic code formatting in vsCode is much better than in Google Slides.
In the future, it would be way better if I used a monorepo to store the example code and the deck in the same repo. Next time: