[wp-hackers] How to test a plugin before release?
bryan at ibaku.net
Mon Sep 9 22:01:14 UTC 2013
On Mon, Sep 9, 2013 at 3:08 PM, Michael Clark wrote:
> So, how should I be testing my plugin?
Stop looking at the problem from the perspective that you might need
to build a huge matrix of all sorts of versions of WordPress with
various popular pre-installed plugins combined with different versions
of PHP, and using different major settings like multisite. This is
still partially true, but it's not going to help you. Instead, there's
two major tactics that all plugin developers should be adopting that
mainly avoids this issue.
1. Use programming techniques that avoid conflicts and problems with
other plugins to begin with:
a. Prefix your global methods and classes (or use namespaces if using
OOP and requiring PHP 5.3+ with your plugin) and isolate 3rd party
libraries as a separate service layer if it frequently conflicts with
other common plugins also importing the same library (hide it behind a
separate web-requested PHP script that doesn't include WordPress if
b. Use your best judgement on ensuring all actions, hooks, and filters
you tie into have an appropriate priority level compared with how
other plugins use those same hooks if you need to use them, and always
make sure your filters return the exact same content if they don't
actually do anything with that content.
classes on elements, avoid HTML element IDs, and use common built in
HTML element classes to pick up common theme styles.
d. If you want your plugin to work as far back as PHP 5.2 (and you
should since WP supports it), consider doing all of your development
in PHP 5.2 first, and then testing 5.4+ later - you can quickly get
used to the same old habits you used to have of *not* using
namespaces, closures, traits, short array syntax, etc.
e. I'm sure there's techniques others here could add to this list...
2. Add unit tests to your plugins, and think about configuring them
with a continuous integration server like Travis CI.
This will in fact build out a matrix of various configurations for you
covering multiple versions of WordPress, PHP, and multisite (and
common plugins if you customize it to), and run your unit tests across
*all* of them in a fully automated way that you can perform in as
little as a few minutes right before you tag a new release.
I've given a WordCamp presentation on this exact topic if it helps:
Also see: https://github.com/tierra/wordpress-plugin-tests
When you have the hang of those two techniques, the only issues you
end up actually running into are mostly browser-specific bugs with
HTML/CSS. It's much harder to implement automated cross-browser
testing to locate and prevent these bugs before getting reports on
them, but they are usually minor anyway. You might still consider a
service like spoon.net/browsers , browsershots.org or browserstack.com
to help with that if you frequently run into those types of issues.
More information about the wp-hackers