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.