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:
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 ;).
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
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 🙂
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.
We’ll write some actual tests.
We’ll look at code coverage to get some metrics on the quality of our tests, and get something we can present to clients.
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.