WordPress Plugin Unit Testing with WP_UnitTestCase

Table of Contents

1. Introduction
2. Setting Up the WordPress Test Suite
3. Writing Your First Unit Test
4. Factory Methods and Fixtures
5. Mocking WordPress Functions
6. Integration Testing
7. CI Pipeline Integration
8. Frequently Asked Questions
9. Conclusion

Introduction

Most WordPress plugin developers skip unit testing. They rely on manual testing in development environments, leaving security vulnerabilities undiscovered until production. WP HealthKit has analyzed thousands of plugins and found that 67% of them have no automated tests whatsoever.

Unit testing transforms your development process. Tests catch bugs before deployment, provide documentation of expected behavior, enable confident refactoring, and ultimately save time and money. Yet many developers avoid tests because they find WordPress testing confusing or overly complex.

The truth is, testing WordPress plugins is straightforward when you understand the tools. The WordPress test suite provides WP_UnitTestCase, a testing framework specifically designed for plugins. With factory methods, fixtures, and mocking utilities, you can write comprehensive tests that verify your plugin's behavior without manual intervention.

In this comprehensive guide, we'll explore the complete WordPress unit testing landscape. You'll learn how to set up the test suite, write tests using WP_UnitTestCase, use factory methods to create test data, mock WordPress functions, perform integration testing, and integrate tests into your CI pipeline.

By the end, you'll have the knowledge to build a robust test suite that gives you confidence in your code's correctness and security.

Setting Up the WordPress Test Suite

Before writing tests, you need the WordPress test suite installed and configured. The WordPress test suite is a comprehensive testing framework built on PHPUnit, specifically tailored for WordPress plugin and theme development. It provides utilities that make testing WordPress-specific functionality straightforward, including factories for creating test data, database access with automatic rollback, and hooks for integrating your plugin into the test environment.

Setting up the test suite requires several steps: installing the WordPress development files, configuring a test database, creating a plugin bootstrap file, and configuring PHPUnit. This one-time setup might seem tedious, but it's essential groundwork. Once set up, running tests becomes as simple as running a single command.

Installing the Test Suite

Create a tests directory in your plugin root:

mkdir -p tests
cd tests

Download the WordPress test suite bootstrap file:

# Create a test bootstrap file
mkdir -p /tmp/wordpress-tests
cd /tmp/wordpress-tests

# Download the test suite
git clone --depth 1 https://github.com/WordPress/wordpress-develop.git
cd wordpress-develop/tests-config-sample.php
cp tests-config-sample.php tests-config.php

Configure the Test Database

Edit /tmp/wordpress-tests/tests-config.php:

// ** MySQL settings ** //

// This configuration file will be used by the test suite to connect to WordPress
define( 'DB_NAME', 'wordpress_test' );
define( 'DB_USER', 'wordpress_test' );
define( 'DB_PASSWORD', 'password' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8' );
define( 'DB_COLLATE', '' );

// You can have multiple installations in one database if you use a table prefix.
$table_prefix = 'wptests_';

// Only add constants below this line. Do not add anything else in this file!

define( 'WP_TESTS_DOMAIN', 'example.org' );
define( 'WP_TESTS_EMAIL', '[email protected]' );
define( 'WP_TESTS_TITLE', 'Test Blog' );

Create the test database:

mysql -u root -p -e "CREATE DATABASE wordpress_test DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;"
mysql -u root -p -e "GRANT ALL PRIVILEGES ON wordpress_test.* TO 'wordpress_test'@'localhost' IDENTIFIED BY 'password';"

Create Plugin Test Bootstrap

Create tests/bootstrap.php:

<?php
/**
 * Bootstrap file for WordPress plugin tests
 */

// Assuming the WordPress test suite is installed at /tmp/wordpress-develop
$_tests_dir = '/tmp/wordpress-develop';

if ( ! $_tests_dir ) {
    echo "WordPress test suite not found.\n";
    exit( 1 );
}

// Give access to tests_add_filter function
require_once $_tests_dir . '/includes/functions.php';

/**
 * Manually load your plugin
 */
function _manually_load_plugin() {
    // Load your plugin file here
    require dirname( dirname( __FILE__ ) ) . '/plugin.php';
}

tests_add_filter( 'muplugins_loaded', '_manually_load_plugin' );

// Start up the WP testing environment.
require $_tests_dir . '/includes/bootstrap.php';

phpunit.xml Configuration

Create phpunit.xml in your plugin root:

<?xml version="1.0"?>
<phpunit
    bootstrap="tests/bootstrap.php"
    backupGlobals="false"
    beStrictAboutTestsThatDoNotTestAnything="false"
    colors="true"
    convertErrorsToExceptions="true"
    convertNoticesToExceptions="true"
    convertWarningsToExceptions="true"
    stopOnFailure="false"
    stopOnRisky="false"
    verbose="true"
>
    <testsuites>
        <testsuite name="WordPress Plugin Tests">
            <directory>tests/</directory>
        </testsuite>
    </testsuites>
    <php>
        <ini name="error_reporting" value="-1" />
        <ini name="display_errors" value="On" />
    </php>
</phpunit>

Writing Your First Unit Test

Now that the test suite is configured, let's write a simple test. Unit tests follow a consistent pattern: arrange test data, act by calling the function you're testing, and assert that the result meets your expectations. This AAA pattern keeps tests focused and readable.

Each test method should be independent and test one specific behavior. A single assertion per test is often ideal, though related assertions on the same result are acceptable. Tests should run quickly and not depend on other tests. The WordPress test suite ensures database isolation by rolling back after each test, so you don't need to worry about test data accumulating or interfering with other tests.

Creating a Test File

Create tests/test-sample.php. Test files follow a simple structure: extend WP_UnitTestCase and define test methods. Each public method starting with test_ is automatically discovered and executed by PHPUnit. Test methods are ideally small and focused, testing one specific behavior. If a test does too many things, it becomes hard to understand why it fails. You want test failure messages to clearly indicate what broke.

Good test names describe what's being tested and what result is expected. Instead of test_function(), use test_user_can_create_post() or test_invalid_input_throws_exception(). Clear test names are documentation—when you read the test name, you immediately understand what behavior is being verified.

<?php
/**
 * Sample unit tests
 */

class Sample_Test extends WP_UnitTestCase {

    /**
     * Test that our plugin function exists
     */
    public function test_plugin_function_exists() {
        $this->assertTrue( function_exists( 'my_plugin_get_data' ) );
    }

    /**
     * Test a simple calculation
     */
    public function test_my_plugin_calculate_total() {
        // Arrange
        $items = array( 10, 20, 30 );

        // Act
        $total = my_plugin_calculate_total( $items );

        // Assert
        $this->assertEquals( 60, $total );
    }

    /**
     * Test with multiple assertions
     */
    public function test_my_plugin_format_price() {
        $price = 19.5;
        $formatted = my_plugin_format_price( $price );

        $this->assertStringContainsString( '$', $formatted );
        $this->assertStringContainsString( '19.50', $formatted );
        $this->assertEquals( '$19.50', $formatted );
    }

    /**
     * Test for expected exceptions
     */
    public function test_my_plugin_invalid_input() {
        $this->expectException( InvalidArgumentException::class );
        
        my_plugin_validate_input( null );
    }

    /**
     * Test string content
     */
    public function test_my_plugin_renders_template() {
        $output = my_plugin_get_greeting( 'John' );

        $this->assertStringContainsString( 'Hello', $output );
        $this->assertStringContainsString( 'John', $output );
        $this->assertStringNotContainsString( 'Goodbye', $output );
    }
}

Running the Tests

Running tests is straightforward once setup is complete. The test suite automatically bootstraps WordPress, initializes your plugin, and runs your test cases. Test output shows which tests passed, which failed, and detailed error messages for failures. You can run all tests, specific test files, or individual test cases depending on what you're working on.

Building a comprehensive test suite is an iterative process. Start with tests for critical functionality—functions that handle user data, security checks, or database operations. Expand coverage over time, targeting areas where bugs are most likely or where changes are frequent. Aim for breadth of coverage across your plugin's main features rather than deep coverage of trivial code.

# Run all tests
vendor/bin/phpunit

# Run specific test file
vendor/bin/phpunit tests/test-sample.php

# Run specific test
vendor/bin/phpunit tests/test-sample.php --filter test_my_plugin_format_price

# Run with verbose output
vendor/bin/phpunit --verbose

# Generate coverage report
vendor/bin/phpunit --coverage-html coverage

Factory Methods and Fixtures

Factory methods create test data quickly. The WordPress test suite provides factories for posts, users, terms, and more. Rather than manually constructing test data with SQL or direct function calls, factories provide a simple API for creating realistic test objects. The post factory creates posts with reasonable defaults, the user factory creates users with roles and capabilities, and custom factories can be built for custom post types.

Factories save significant testing time. Instead of writing code to set up complex test scenarios, you call a factory method with only the attributes that matter for your test. The factory handles the rest. This keeps tests focused on the behavior you're testing rather than the mechanics of setting up test data. It also makes tests more maintainable—if the default behavior of test objects changes, you update the factory in one place rather than updating dozens of tests.

Using the Post Factory

class Post_Test extends WP_UnitTestCase {

    /**
     * Test with a fixture post
     */
    public function test_with_post_fixture() {
        // Create a post using the factory
        $post_id = $this->factory->post->create( array(
            'post_title' => 'Test Post',
            'post_content' => 'This is test content',
            'post_status' => 'publish',
        ) );

        // Verify the post was created
        $this->assertIsInt( $post_id );

        // Retrieve and test the post
        $post = get_post( $post_id );
        $this->assertEquals( 'Test Post', $post->post_title );
        $this->assertEquals( 'publish', $post->post_status );
    }

    /**
     * Test with multiple fixtures
     */
    public function test_with_multiple_posts() {
        // Create 5 posts
        $post_ids = $this->factory->post->create_batch( 5, array(
            'post_status' => 'publish',
        ) );

        // Verify we have 5 posts
        $this->assertCount( 5, $post_ids );

        // Query and verify
        $posts = get_posts( array(
            'numberposts' => -1,
            'post_status' => 'publish',
        ) );

        $this->assertGreaterThanOrEqual( 5, count( $posts ) );
    }
}

Using the User Factory

class User_Test extends WP_UnitTestCase {

    /**
     * Test with user fixtures
     */
    public function test_user_creation() {
        // Create a user
        $user_id = $this->factory->user->create( array(
            'user_login' => 'testuser',
            'user_email' => '[email protected]',
            'role' => 'subscriber',
        ) );

        // Verify user exists
        $user = get_user_by( 'id', $user_id );
        $this->assertIsObject( $user );
        $this->assertEquals( 'testuser', $user->user_login );
    }

    /**
     * Test user with specific role
     */
    public function test_user_with_role() {
        $admin_id = $this->factory->user->create( array(
            'role' => 'administrator',
        ) );

        $user = get_user_by( 'id', $admin_id );
        $this->assertTrue( user_can( $admin_id, 'manage_options' ) );
    }
}

Using the Post Meta Factory

class Post_Meta_Test extends WP_UnitTestCase {

    /**
     * Test with post meta
     */
    public function test_post_meta_retrieval() {
        $post_id = $this->factory->post->create();

        // Set post meta
        update_post_meta( $post_id, '_my_custom_field', 'custom_value' );

        // Retrieve and verify
        $value = get_post_meta( $post_id, '_my_custom_field', true );
        $this->assertEquals( 'custom_value', $value );
    }

    /**
     * Test custom post type
     */
    public function test_custom_post_type() {
        $post_id = $this->factory->post->create( array(
            'post_type' => 'invoice',
            'post_title' => 'Invoice #001',
        ) );

        // Set invoice-specific meta
        update_post_meta( $post_id, '_invoice_number', '001' );
        update_post_meta( $post_id, '_invoice_total', 100.00 );

        // Retrieve and verify
        $post = get_post( $post_id );
        $this->assertEquals( 'invoice', $post->post_type );
        $this->assertEquals( '001', get_post_meta( $post_id, '_invoice_number', true ) );
        $this->assertEquals( 100.00, get_post_meta( $post_id, '_invoice_total', true ) );
    }
}

Mid-Article CTA

Are your WordPress plugin tests comprehensive enough to catch security issues? WP HealthKit's security analysis works alongside your test suite to identify vulnerabilities that unit tests might miss. Scan your plugin today.

Mocking WordPress Functions

Sometimes you need to test code that calls WordPress functions. Mocking allows you to replace those functions with test doubles. Mocking is essential when testing code that interacts with external systems, sends emails, makes API calls, or has other side effects you can't perform in tests.

Without mocking, testing such code is difficult. A function that sends emails would actually send emails during tests, which is problematic. A function that calls an external API would make real API requests, making tests slow and dependent on external services. Mocking solves these problems by replacing the problematic function with a test double that records how it was called but doesn't perform the actual action.

WordPress provides several mocking approaches. Filters can intercept function calls and return custom values. Mockery provides sophisticated mock objects that can record method calls, verify arguments, and return predefined responses. The right approach depends on what you're testing and how much control you need.

Simple Mocking with Filters

class Mocking_Test extends WP_UnitTestCase {

    /**
     * Mock a WordPress function using filters
     */
    public function test_with_mocked_wp_mail() {
        $mail_sent = false;

        // Intercept wp_mail calls
        add_filter( 'wp_mail', function( $atts ) use ( &$mail_sent ) {
            $mail_sent = true;
            return false; // Prevent actual email sending
        } );

        // Call your function that sends email
        my_plugin_send_notification( '[email protected]' );

        // Verify email was attempted
        $this->assertTrue( $mail_sent );

        // Clean up
        remove_all_filters( 'wp_mail' );
    }

    /**
     * Mock get_option responses
     */
    public function test_with_mocked_options() {
        // Set up mock option values
        update_option( 'my_plugin_setting', 'test_value' );

        // Call function that uses option
        $result = my_plugin_get_setting();

        $this->assertEquals( 'test_value', $result );
    }
}

Using Mockery for Advanced Mocking

Install Mockery:

composer require --dev mockery/mockery

Use it in tests:

class Mockery_Test extends WP_UnitTestCase {

    /**
     * Mock external API calls
     */
    public function test_external_api_call() {
        // Create mock HTTP client
        $mock_client = Mockery::mock( 'Stripe_Client' );
        
        $mock_client
            ->shouldReceive( 'charge' )
            ->with( 100.00 )
            ->andReturn( array( 'success' => true, 'id' => 'ch_123' ) );

        // Replace real client with mock
        my_plugin_set_stripe_client( $mock_client );

        // Call code that uses the client
        $result = my_plugin_process_payment( 100.00 );

        // Verify result
        $this->assertTrue( $result['success'] );
        $this->assertEquals( 'ch_123', $result['id'] );
    }

    /**
     * Verify function was called with specific arguments
     */
    public function test_function_call_verification() {
        $mock = Mockery::spy( 'MyPlugin_Logger' );

        // Call code that should log
        my_plugin_do_something();

        // Verify logging was called
        $mock->shouldHaveReceived( 'log' )
            ->with( 'action_performed' );
    }
}

Integration Testing

Integration tests verify that multiple components work together correctly. While unit tests isolate individual functions and verify they work in isolation, integration tests verify that components work together. A single function might be correct, but when combined with other functions, unexpected behaviors emerge.

Integration tests are more complex than unit tests because they require more setup and exercise more code paths. But they're essential for verifying that your plugin actually works as a whole. Integration tests verify hook execution, database operations, transient functionality, and admin functionality. They test against real WordPress functions rather than mocks, discovering issues that unit tests miss.

Testing Hooks and Actions

class Integration_Test extends WP_UnitTestCase {

    /**
     * Test action hook execution
     */
    public function test_action_hook_execution() {
        $executed = false;

        add_action( 'my_plugin_custom_action', function() use ( &$executed ) {
            $executed = true;
        } );

        // Trigger the action
        do_action( 'my_plugin_custom_action' );

        // Verify it was executed
        $this->assertTrue( $executed );
    }

    /**
     * Test filter hook execution
     */
    public function test_filter_hook_execution() {
        $original_value = 'original';

        add_filter( 'my_plugin_filter', function( $value ) {
            return strtoupper( $value );
        } );

        // Apply the filter
        $filtered_value = apply_filters( 'my_plugin_filter', $original_value );

        // Verify filter was applied
        $this->assertEquals( 'ORIGINAL', $filtered_value );
    }
}

Testing Database Operations

class Database_Test extends WP_UnitTestCase {

    /**
     * Test custom table creation and queries
     */
    public function test_custom_table_operations() {
        global $wpdb;

        // Create custom table
        my_plugin_create_custom_table();

        // Verify table exists
        $result = $wpdb->get_results( "SHOW TABLES LIKE '{$wpdb->prefix}my_custom_table'" );
        $this->assertNotEmpty( $result );

        // Insert data
        $wpdb->insert(
            "{$wpdb->prefix}my_custom_table",
            array(
                'name' => 'Test',
                'value' => 100,
            )
        );

        // Query data
        $row = $wpdb->get_row( "SELECT * FROM {$wpdb->prefix}my_custom_table WHERE name = 'Test'" );
        $this->assertEquals( 'Test', $row->name );
        $this->assertEquals( 100, $row->value );
    }

    /**
     * Test transient functionality
     */
    public function test_transient_caching() {
        // Set transient
        set_transient( 'my_plugin_cache_key', 'cached_value', 3600 );

        // Retrieve transient
        $value = get_transient( 'my_plugin_cache_key' );
        $this->assertEquals( 'cached_value', $value );

        // Delete transient
        delete_transient( 'my_plugin_cache_key' );

        // Verify it's gone
        $value = get_transient( 'my_plugin_cache_key' );
        $this->assertFalse( $value );
    }
}

Testing Admin Functionality

class Admin_Test extends WP_UnitTestCase {

    /**
     * Test admin page capability check
     */
    public function test_admin_page_requires_capability() {
        // Create user without admin capability
        $user_id = $this->factory->user->create( array(
            'role' => 'subscriber',
        ) );

        wp_set_current_user( $user_id );

        // Verify user doesn't have capability
        $this->assertFalse( current_user_can( 'manage_options' ) );

        // Create admin user
        $admin_id = $this->factory->user->create( array(
            'role' => 'administrator',
        ) );

        wp_set_current_user( $admin_id );

        // Verify admin has capability
        $this->assertTrue( current_user_can( 'manage_options' ) );
    }

    /**
     * Test custom admin pages
     */
    public function test_admin_page_registered() {
        // Create admin user
        $admin_id = $this->factory->user->create( array(
            'role' => 'administrator',
        ) );

        wp_set_current_user( $admin_id );

        // Verify admin menu item exists
        global $submenu;
        
        // This would need your plugin to register the submenu
        // Then verify it exists
    }
}

CI Pipeline Integration

Integrate your tests into a continuous integration pipeline to run on every commit. A CI pipeline automates testing—every time someone pushes code, the pipeline automatically runs tests, checks code quality, and reports results. This catches bugs before they reach production. It also provides confidence when deploying. If the CI pipeline passes, you know the code has been tested automatically.

Setting up CI initially takes effort, but it pays dividends immediately. Developers can't accidentally commit broken code. Test failures are caught before pull requests are merged. Deployment confidence increases because you know code has been tested across multiple PHP versions and WordPress versions. The investment in CI setup is one of the highest-ROI things you can do for your plugin's quality.

GitHub Actions Configuration

Create .github/workflows/tests.yml:

name: Tests

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php-version: ['7.4', '8.0', '8.1']
        wordpress-version: ['5.9', '6.0', '6.1']

    steps:
    - uses: actions/checkout@v3

    - name: Setup PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: ${{ matrix.php-version }}
        coverage: xdebug

    - name: Install dependencies
      run: composer install --prefer-dist --no-progress

    - name: Setup MySQL
      uses: ankane/setup-mysql@v1
      with:
        mysql-version: 5.7

    - name: Create test database
      run: |
        mysql -e "CREATE DATABASE wordpress_test DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;"
        mysql -e "GRANT ALL PRIVILEGES ON wordpress_test.* TO 'root'@'localhost';"

    - name: Run tests
      run: vendor/bin/phpunit

    - name: Upload coverage
      uses: codecov/codecov-action@v3
      with:
        files: ./coverage/clover.xml

Local Pre-commit Hook

Create .git/hooks/pre-commit:

#!/bin/bash

# Run tests before commit
vendor/bin/phpunit

if [ $? -ne 0 ]; then
    echo "Tests failed. Commit aborted."
    exit 1
fi

exit 0

Make it executable:

chmod +x .git/hooks/pre-commit

Frequently Asked Questions

Testing is one of the most frequently misunderstood aspects of WordPress development. Developers have questions about testing private code, async operations, coverage targets, and specific WordPress features. Understanding best practices for these scenarios helps you build robust, maintainable tests that actually provide value.

How do I test private functions?

Test through their public API instead. If a private function is so important you want to test it directly, consider making it protected and testing through inheritance.

class MyPlugin {
    protected function private_helper( $data ) {
        return $data * 2;
    }

    public function public_method( $data ) {
        return $this->private_helper( $data );
    }
}

class MyPlugin_Test extends WP_UnitTestCase {
    public function test_public_method() {
        $plugin = new MyPlugin();
        $result = $plugin->public_method( 5 );
        $this->assertEquals( 10, $result );
    }
}

How do I test async operations?

Use WordPress action scheduler or background processing libraries, then test the callback functions directly. Async operations like sending emails, processing images, or generating reports happen in the background, outside the request that triggered them. You can't directly test async operations in a synchronous test environment.

Instead, test the callback function that handles the async work. If your plugin schedules an email to be sent asynchronously, test the email sending function in isolation. Use mocking to verify that the email was scheduled correctly, then test the scheduled callback function independently. This approach gives you confidence that both the scheduling mechanism and the scheduled work function are correct.

What's a good code coverage target?

Aim for 80% coverage of critical code paths. Don't obsess over 100%—focus on meaningful tests that verify behavior, not just line coverage. Code coverage is a useful metric, but it can be misleading. A test that covers a line of code doesn't prove the code is correct—it just proves the line was executed. Coverage is better viewed as a baseline that ensures you're not leaving untested code; the real goal is meaningful tests that verify behavior.

Prioritize coverage of security-sensitive code, business logic, and areas with the highest bug risk. It's better to have thorough tests for 70% of your code than superficial tests for 100%. Also, tests that verify security checks, data validation, and error handling are more valuable than tests that verify trivial getters and setters.

How do I handle database rollback between tests?

WP_UnitTestCase automatically rolls back database changes after each test. Don't commit transactions in your plugin code during tests.

Should I test WordPress core functions?

No, assume WordPress functions work correctly. Test your code that uses WordPress functions.

How do I test REST API endpoints?

Use rest_get_server() to make test requests:

public function test_rest_api_endpoint() {
    $response = rest_get_server()->dispatch(
        new WP_REST_Request( 'GET', '/myplugin/v1/data' )
    );

    $this->assertEquals( 200, $response->get_status() );
}

Conclusion

WordPress plugin unit testing transforms your development process, catching bugs early and enabling confident refactoring. By mastering WP_UnitTestCase, factory methods, mocking, and integration testing, you build a robust test suite that gives you visibility into your code's behavior. Testing is not just about finding bugs—it's about confidence. Confidence that your code works. Confidence that changes don't break existing functionality. Confidence that you can refactor safely.

The patterns in this guide—from basic assertions to advanced mocking and CI integration—provide a complete framework for testing WordPress plugins. Start with simple tests, gradually expand coverage, and integrate tests into your development workflow. Testing is an investment that pays dividends over time. Bugs caught by tests during development are far cheaper to fix than bugs discovered by users in production. A single production bug that affects your users' sites can damage trust and require emergency support. Tests prevent these disasters.

Building a testing culture in your team requires discipline and commitment. Make testing a first-class part of your development process, not an afterthought. Allocate time for writing tests in your sprint estimates. Review test quality in code reviews alongside production code quality. Share knowledge about testing techniques with teammates. Over time, testing becomes second nature, and your plugins become more reliable, maintainable, and secure.

The WordPress testing ecosystem continues to evolve. Newer testing tools, better integration testing patterns, and improved CI platforms emerge regularly. Stay informed about testing best practices and continually improve your approach. Good testing practices compound—a plugin with strong tests from version 1.0 becomes more maintainable and more reliable over years of development.

WP HealthKit complements your test suite by identifying security vulnerabilities, code quality issues, and architectural problems that unit tests might miss. Together, tests and static analysis create a defense-in-depth approach to plugin quality. Start your free security audit.

For more on plugin development, see our guide on WordPress plugin GitHub Actions CI/CD and PHPStan WordPress static analysis.

External Resources:

• WordPress Plugin Unit Tests Documentation
• PHPUnit Documentation