While unit testing is a big deal in many development communities (Ruby on Rails for example) it’s not something the typical WordPress developer does and that’s a crying shame.
Even many of the really good WordPress developers often aren’t doing unit testing.
Even worse the few that are assume a huge level of knowledge is had by readers of their content. That is if they even write about it.
The few more beginner oriented resources on unit testing stop at beginner level. They don’t take your from ‘0 to hero’ as it were.
My goal is to teach you the basics of how to unit test your work and walk you through to a fairly advanced level with a library of test patterns to use for various scenarios.
Over the course of this series on Unit Testing we’ll cover
- Tools of the trade like PHPUnit, WP_Mock, Travis CI
- Starting to write some tests
- Building out a decent library of test patterns
- and more
Let’s get started by looking at what unit testing is.
What is Unit Testing
Unit testing is the practice of writing automated tests that can be run against your functions/methods to verify their output.
This lets us make sure that our code works as we expect it to work. It helps us to verify the quality of our code as we can also send it bad data and make sure that bad data is handled properly according to our tests.
Why Should you be Unit Testing
Let start with a story. We’ll call our protagonist Curtis M to preserve his identity. He had just shipped a huge client site. It had 3 types of roles with lots of custom capabilities.
It had a custom calendar that looked back to custom post types for bookings and custom post types that interfaced with notes that our coaches could take on students.
He shipped it with a bug, which happens. His client reported the bug and he went in and ‘fixed’ it.
Unfortunately it had been 3 weeks since he wrote the code and since it wasn’t fresh in his mind, he broke another part of the system.
Two weeks later the client found that bug and came back with a request to fix it.
So Curtis M fixed it and guess what…yeah there was another bug.
Eventually Curtis M did close up the project but his extra bug fixing time turned it in to a project without profit so he was grumpy.
Less code breaking
If we skip the technical jargon, we should write tests for our code because it means that we’re less likely to break things when you make changes later. You’ll know that your current changes don’t break old code because your tests still pass.
Then you can have a party.
Simpler Testable code
If you’re planning on unit testing your code you’re going to write code that is easily testable which means you’re likely to end up with smaller abstracted methods or functions.
So no massive 300 line functions combining logic and HTML and more logic. More likely it will be 4 or 5 functions with the logic cleanly separated out and the HTML built in a single function.
Since a function only does one thing you should end up with better function names which will also make your code easier to read. Code that’s easier to read is a good thing not only for the next developer that comes to the project, but for you in 6 months who has totally forgotten exactly what you did on the project.
Before testing my typical development cycle was something like:
- Make some edits
- Go to my browser
- Add needed data
- Save data
- Check for output (WP_DEBUG is on right?)
- Click around the WordPress admin or the rest of the site once I think I’m done and find where my code broke something else
- Deal with clients finding problems later that you didn’t think of
Once I started testing it looks like:
- Make some edits
- Run phpunit in my terminal
- Check results
- Fix issues or move on
The biggest time saver is that later when I write new code I can run those tests and I can tell if something is broken. I don’t have to spend the time clicking around my browser to make sure that things are working properly, my tests tell me.
The net time saved of my tests telling me if something works is HUGE compared to the time it takes you to click around a browser and you’re going to forget to click something.
Tests First or Last?
If your going with a formal Test Driven Development (TDD) methodology you’re actually going to write your tests first. That means you’ll figure out what a particular function is supposed to do and then write the test to make sure it does it properly.
Then you write the actual code needed to pass the test. The code you write is the minimum possible needed to pass the test. That may mean you only test for a boolean value returning true, and all your function does is return true.
Going this method helps you keep your code lean and tight as well. You start out writing a test to check for an array, then as you write the code you realize there are a few other steps needed but you still build your function for that specific array and you break out the other functionality it to separate functions you can also test.
You build out the other pieces you need and test those. Hence it’s likely that you have smaller easily testable functions/methods around.
Testing after would mean you build out your functionality and then write your tests for the functionality and it called Regression Testing. So you write the tests to pass as things work now.
That may mean you write it so that current bugs pass the tests. It will help you find bugs in your code though.
Overall writing tests firsts typically results in better code quality so work towards TDD.
One Final Story
This story is about a completely different developer but we’ll still protect his identity by calling him C McHale.
He wrote a plugin for Restrict Content Pro and did some regression testing on it. He found that a filter he thought was working wasn’t quite working as expected so he fixed it.
Fixing it broke one of his other tests, so he fixed that as well.
No one knew that both broke. He never shipped broken code.
The total turn around for fixing both items was small. Even the tests were written in an hour.
Next time we’ll walk through some of the tools that you will come across as you look at unit testing in WordPress.