Automated UI Testing for WordPress

Avatar for Jordan Kohl

Jordan Kohl

Senior Engineer

15 May 2019

Graphic for blog post Automated UI Testing for WordPress

Many websites and even applications online are built on top of a CMS. According to recent survey data, WordPress has a 60% market share, making it the most popular CMS by far. The next closest competitor, Joomla, has only 5.2%! But unlike bespoke software, many people don’t test their WordPress website. While the core of WordPress is fairly well tested by it’s creators, users, and the open source community, the same cannot be said for every plugin and theme. There’s an infinite combination of versions, hosting environments, plugins, themes, and configurations. You can’t trust the community to catch every bug that could affect your website.

Applying automated UI testing to the public-facing pages of a WordPress website is just like testing anything else. However there are as many plugins for the administration panel as there are for the public pages. In addition, you might be creating plugins and themes of your own that you want to test. This post will cover how to write automated tests that can login into your WordPress admin, install plugins, and modify settings.

Tips for Getting Started

If you’re going to use Ghost Inspector to test your WordPress admin, here are a few tips to get started:

  1. We strongly suggest running tests on a testing/staging environment. However, if you need to test on production then be sure to create a new user for UI tests. Instead of putting your own username/password into the automated tests, create a specific user that can you easily disable or limit access. This will also help ensure your tests don’t break because you needed to reset your own password.
  2. Use private values for test input, especially passwords. That will prevent anyone viewing your tests from also immediately seeing your WordPress login info.
  3. Use suite-level variables for things like username/password. That way you only have one place to update if you do need to change the password.

Use Case: Plugin Installation

The following is a test we maintain for our official WordPress plugin. In this example I’ll show you how to install a plugin from the official WordPress directory, activate it, modify it’s settings, and verify it’s being displayed as expected. You should be able to use many of these same steps to test installing and modifying any plugin or theme.

Login to WordPress Admin

Below are the steps for logging into any WordPress admin. You can import these exact steps into your own suite by downloading this Selenium IDE .html export (unzip before import).

Graphic for blog post undefined

What is this test doing? Step 1 is conditional, based on the current URL. If is not the WordPress login, it will Go to /wp-login.php.

Step 2 & 3 enter the username and password.

Step 4 submits the form and logs into the admin.

Step 5 asserts that the login was successful by checking that it’s on the Dashboard page.

That’s it! This test can be reused in other tests that need to login first.

Check if Plugin is Already Installed

Graphic for blog post undefined

What’s happening here? Like any good test, we want to start with fresh data every time. Since this is testing that a plugin can be installed and activated, the test should always start without the plugin installed. But, because we are testing against a live site, the plugin might already be there. So this set of steps finds and uninstalls the plugin before doing anything else.

Step 1 imports the login steps we just covered.

Step 2 navigates to the plugins section of the admin.

Step 3 (and step 4) are conditional and only run if an element with our plugin slug (in this case, ghost-inspector) is found. This step deactivates the plugin. It is optional in case the plugin is installed but not activated. If you want to use this with your own plugin, simply change the slug and full name. This test is using both, but it could be simplified by only using one or the other.

Step 4 uninstalls the plugin. Note the use of aria-label and data-slug again. While these could change, they are pretty standard parts of WordPress so they should remain for a long time.

Installing a Plugin from the WordPress Directory

Graphic for blog post undefined

In these steps, the test searches for a plugin by name, then installs and activates it.

Step 5 clicks the "Add New" button on the plugin page.

Step 6 searches for "ghost inspector" (replace this with any search term to find the plugin you want).

Step 7 installs the plugin using the class that WordPress applies to the plugin cards, in this case .plugin-card-ghost-inspector.

Step 8 activates the plugin that was just installed.

Changing Plugin Settings

Graphic for blog post undefined

Now the test navigates to the plugin settings screen, updates some values and saves. These steps are specific to this plugin, but similar logic could be applied to other plugins or settings screens.

Step 9 clicks the Settings menu in WordPress.

Step 10 navigates to the settings page specific to this plugin.

Step 11 & 12 assign data to the various settings fields for the plugin.

Step 13 submits the form to save the settings.

Step 14 verifies that the settings saved successfully.

Verifying Plugin Features

Graphic for blog post undefined

These final steps verify that the plugin is showing the expected output. This test is pretty basic, but could be expanded for a more complex plugin.

Step 15 navigates to the admin dashboard where our plugin widget is displayed.

Step 16, 17, & 18 verify some specifics about our plugin based on the settings we entered. Replace these with whatever business logic you need to test.

That’s it! As you can see in the notes (TODO) there’s plenty of room for improving and expanding these tests. You’ll have to adapt these steps for your own needs, but hopefully this gives you an idea of how to apply UI automation testing to your WordPress admin using Ghost Inspector.

Making Your Tests Portable

While your first tests are probably for your live site, you might have a staging or local environment that need to be tested as well. Or you might want to use the same test for multiple WordPress sites. Here are some tips for making your tests more portable:

Share this post