The more work I do in WordPress, the more I try to make unit testing as much a part of my development as building out the actual feature set. (It’s what all the professionals say we need to do, anyway.)

But seriously, it does improve the quality because, if for no other reason, something breaks, you’re able to see which test fails or even if you’ve missed coverage in some area.

I’m not of the mindset of some that you have to have 100% code coverage (and there are reasons for why I think this), but I do think it’s important to have as much code coverage as possible of code that is not directly to WordPress.

Testing Code in WordPress

I don’t know if that sounds confusing or not, but one of the traps I fell into early on when working with unit testing and WordPress was writing tests against core WordPress code.

I still do this sometimes (and you can ask those with whom I work if this is true), though I’m getting better about it.

As far as I’m concerned, WordPress itself can be treated as a black box. It’s a foundation on which your application lives. There are already tests around WordPress core. Should there be more? Sure. Is what they have sufficient? In my experience, yes, but we all use a different subset of said features.

Testing Code in WordPress

The point that I’m getting that is this: Each time you work on a project that’s built on WordPress; you don’t need to write tests against code like add_menu_page or wp_enqueue_script.

We know those functions work.

Instead, focus on the code that’s specific to your domain. That is, focus on the code you and your team write. That’s going to be the area of specialty that’s unique in the project, and that’s going to be the area that’s ultimately responsible for solving a given problem.

If you aim to get 100% coverage just for the sake of 100% coverage, then you aren’t writing unit tests for the right reason. Instead, aim for whatever the highest degree of code coverage is that sufficiently tests your code. That is what will enforce quality.