The imperative to “test your software” has many different connotations ranging from checking the website to see if it generally works to validating an API. It’s something that a client always expects — but rarely has a clear grasp of what it entails.
In this course, we’re going to look at “automated” testing — or, as some would call it “regression testing” as something you can add to your toolbox.
Regression Testing has its roots in its name: developers created tests that verified the expected functioning of their software’s components. Then when changes were made, they ran the regression tests to verify nothing broke. We will find this approach to be very powerful in the context of WordPress plugins and themes (which may run updates and changes outside of our control)
Then, along came the “Test Driven Developers” or TDD, who turned the paradigm on it’s head. Write the test for your new behavior first, then write the code to make the test pass. Many devsYours truly, included. find this process a bit too abstract to actually implement– but their red—>green mentality can be helpful when we want to verify a test is actually working.
How you use automated tests will largely depend on your preferred workflow. But in a nutshell they:
- Are Automated meaning they don’t require you to do anything other than maybe run the test command
- Verify the software’s actual outputs match expected values. These expected values can be defined by us, or compared to a historical record.
- Use a testing framework. Within this course we’ll use WP_UnitTest Framework, Jest, and BackstopJS for reasons discussed later.
Given the benefits of Automated testing, it begs the question: Why isn’t it more prevalent?
It doesn’t add features so clients won’t pay for it.
It’s not something I know how to do
I couldn’t get it set up
Good clients will. They just need a little education before signing off, and evidence of the benefit afterwardOur code coverage reports will help with this.
Writing perfect tests is quite difficult. But your tests don’t need to be perfect to offer some benefitI find a bad test is more informative than a good comment.
Environment setup, particularly for the WP_UnitTest Framework can be a bear. Fortunately, we’ve got a cheat code ;).
Myths
Myth
Automated tests only work for OOP code.Truth:You can write automated test for any code that has expected outputs
Myth
You need super high-quality code to write tests for it.Truth:Your code quality will undoubtedly improve as a result of testing — but if you can follow this tutorial, then you can write code good enough to test.
Myth
Regression tests only work for highly atomic/isolated packages Truth:Unit Tests are designed to test components in isolation. But we’re working with WordPress, so nothing’s in isolation. We’ll embrace this and take an integration testing mentality
Myth
The WP_UnitTestCase framework is really only for core contributors. Truth:Nope. It can be used for anything WordPress. And the fine folks at WooEngineering would love it if more extension authors had automated testing in place 🙂
2.
1.
We’ll bypass the tricky parts of environment setup by gently wading into the waters of Docker
Starting with PHP tests, we’ll tweak our bootstrap.php and phpunit.xml files for true integration testing.
3.
We’ll write some actual tests.
5.
4.
We’ll look at code coverage to get some metrics on the quality of our tests, and get something we can present to clients.
Finally, we’ll dive into front end testing with Jest and BackstopJS
Hopefully, by now, your mind is awash in great ideas about how automated testing can make your life easier for software development.
Time to knock out the first big obstacle to getting started, environment setup.
Keyboard shortcuts
Down arrow Next slide
Up arrow Previous slide
Color codes
Hover over text more additional info