[wp-hackers] How to test a plugin before release?

[Bryan Petty]

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
possible).
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.
c. If your plugin writes HTML, CSS, or Javascript, do the same with
that: namespace and prefix JavaScript code, use unique prefixed CSS
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:
https://www.youtube.com/watch?v=9qMUc9anJKQ

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.

-- 
Regards,
Bryan Petty