How to test a WordPress plugin

Write down what the plugin is meant to change before you activate it. Include its settings screen, shortcodes or blocks, front-end output, permissions, forms, emails, scheduled tasks, REST or AJAX requests, and any third-party service it calls.

Also include failure cases: empty fields, invalid values, logged-out visitors, users without the required capability, fresh installation, upgrade from an older version, and a site where another common plugin is active.

Use a local site or staging copy with a database backup. Do not test an unfamiliar or unfinished plugin on a live site because activation can create a fatal error, change stored data, or add scheduled tasks that continue running.

For a repeatable local setup, install Docker and Node.js, install @wordpress/env, move into the plugin directory, and run wp-env start. WordPress documents this as a local environment for building and testing plugins; the default dashboard is available at http://localhost:8888/wp-admin.

Enable WP_DEBUG and WP_DEBUG_LOG on the local or staging site, and set WP_DEBUG_DISPLAY to false if you do not want errors printed into page output. Review wp-content/debug.log after every test run, including browser actions that use AJAX or the REST API.

Clear or record the old log before starting a new test. Debug mode is for development and staging, not for a public production site.

Install the plugin, activate it, and check that the expected settings, database tables, rewrite rules, widgets, blocks, or scheduled events appear. Visit the front end while logged in and logged out, then test each setting and normal user workflow.

Deactivate the plugin and confirm that the site still loads. If the plugin documents removal behaviour, uninstall it on a disposable copy and check whether its options and custom tables are removed as intended. WordPress treats deactivation and uninstall as different operations, so testing only the deactivate button can miss data-cleanup bugs.

For plugin code that will be maintained, add PHPUnit tests for functions and classes, then integration tests for behaviour that depends on WordPress. WP-CLI can scaffold the usual test files with wp scaffold plugin-tests plugin-name --ci=github; the generated setup includes a bootstrap file, PHPUnit configuration, an installation script, and a sample test.

Run the tests against a clean WordPress database and repeat them after changing the plugin. If the test environment reports that its WordPress test library is missing, remove the incomplete temporary test directories and run the installation command again rather than debugging the plugin code first.

If you only need to check that a plugin can be activated, loaded, and exercised without building a full test suite, use a disposable WordPress install and a small test fixture. benign-plugin-test may fit that narrow use: choose it as a lightweight fixture for benign plugin testing, not as a production feature.

The manual route is still the better option when you need compatibility checks, lifecycle cleanup, user permissions, database behaviour, or automated regression tests. A fixture can expose a basic environment problem quickly, but it cannot prove that your real plugin works across themes, PHP versions, WordPress versions, or other plugins.