Tag: Unit Testing (Page 1 of 2)

A Simple Guide for Organizing WordPress-centric Classes

August 9, 2018 / Tom

One of the things that I’ve been making a much more concerted effort, likely more so than I’ve ever done before, is managing separation of concerns between the classes responsible for interfacing with WordPress and those responsible for working with the problem domain.

For instance, let’s say that you’re working on a plugin and it’s going to communicate with a third-party API. Additionally, this plugin will also offer menus, post types, taxonomies, and so on within the WordPress administration area.

There are two areas of responsibility here:

the area responsible for generally solving the problem,
the area responsible for interfacing with WordPress.

You can make the case that it’s important to unit test areas that communicate with WordPress, but I also know these are tried and true APIs that have their own set of tests.

Instead, we should be focusing on unit testing and separating our business logic away from WordPress.

But that’s not the point of this post. Instead, it’s more about a way to potentially lay out a project when a portion of it will be interfacing with WordPress.

When CloverCoverage Fails And Passes Simultaneously

August 1, 2018 / Tom

I’ve talked about the advantages of using GrumPHP in previous posts. One of the tools that we’ve used in projects for the last year or more is Clover.

Photo by Quentin REY on Unsplash

Some time between when we started using it and this week, it would always fail to execute every time on my local machine but not on the machine to which we were deploying our code.

And no, it wasn’t because there were incorrect directives or comments in the unit tests and it wasn’t because PHPUnit was misconfigured (it was executing all of the tests and reporting them as expected).

So what gives?

A Quick Note on Unit Testing Code in WordPress Projects

July 3, 2018 / Tom

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.

Writing Unit Tests with PHPUnit, Part 3: XML Configuration

May 9, 2018 / Tom

In the past posts in this series, I’ve covered the following two topics:

Writing Unit Tests with PHPUnit, Part 1: The Set-Up. A guide to getting started with writing PHPUnit tests through the use of a basic cache and using the setUp method of the framework.
Writing Unit Tests with PHPUnit, Part 2: The Tear Down. A tutorial on how to write unit tests that properly leverage the setUp and tearDown methods of PHPUnit.

Each of the above is meant to provide a primer for how to get started with writing very basic unit tests. Things can get more complex especially as an application or project grows (but that’s always true, right?).

But to make sure one is prepared for that, there’s one final component to unit testing that I believe we should focus on and that’s understanding the PHPUnit XML Configuration File (which you may have seen in other projects as phpunit.xml).

Writing Unit Tests with PHPUnit, Part 2: The Tear Down

April 18, 2018 / Tom

Late last month, I started talking about writing unit tests in PHPUnit for WordPress-based code. This primarily included the idea of setting up PHPUnit, the setUp function, and writing basic tests.

This did not, however, discuss what I know about the tearDown function which is still an important feature of writing using tests. Further, there’s also two ways to consider writing tests for WordPress projects.

Namely:

writing tests specifically for plugins and application-layer functionality,
running unit tests against the WordPress application.

Before moving forward with this particular post, though, I recommend catching up on what I’ve covered thus far. This includes the following posts:

Once you’ve done that, return to this post and let’s continue discussing the tearDown function and what unit tests in the context of WordPress actually look like.