ворд-пресс.рф
Разработка

Тестирование WordPress-плагина: первые PHPUnit и интеграционные тесты

Какие сценарии тестировать в плагине, как разделить unit и integration tests и что считать проверенным результатом.

Опубликовано: 10.10.2026Обновлено: 10.10.2026

Тесты WordPress-плагина нужны не ради зелёного значка CI, а чтобы обновление не ломало работу пользователей. Начинайте с 2–3 критичных сценариев: создание данных, проверка прав и сохранение настроек. Не пытайтесь покрыть весь код за одну итерацию.

Unit и integration: в чём разница

Unit-тест проверяет небольшую часть поведения независимо от базы и самого WordPress. Интеграционный тест загружает WordPress, создаёт пользователя/записи, вызывает хуки или REST-маршрут и проверяет результат. Для большинства типичных WP-плагинов нужны оба уровня.

Подготовка окружения

  1. Используйте отдельную базу тестов, никогда не подключайте PHPUnit к боевой БД.
  2. Выберите версию PHPUnit, совместимую с вашей версией PHP и WordPress test suite.
  3. Подключите WordPress test bootstrap, phpunit.xml и необходимые зависимости по официальной инструкции.
  4. Настройте загрузку тестируемого плагина в bootstrap и отдельную очистку состояния тестов.
  5. Прогоняйте тесты локально и в CI на целевых версиях PHP/WP.

Пример поведения, которое легко проверить

Для чистой функции на PHP достаточно простого теста. Если функция использует get_option() или current_user_can(), нужно подготовить WordPress test suite или подменить зависимости.

<?php
use PHPUnit\Framework\TestCase;

function wpr8_normalize_slug( string $value ): string {
    return strtolower( trim( $value ) );
}

final class NormalizeSlugTest extends TestCase {
    public function test_trims_and_lowercases(): void {
        $this->assertSame( 'example', wpr8_normalize_slug( ' Example ' ) );
    }
}

Это упрощённая иллюстрация одного unit-теста, а не полный конфиг PHPUnit. Реальные slug-правила WordPress и обработку Unicode проверяйте отдельными случаями (например, через sanitize_title() в интеграционных тестах).

Какие тесты важны для WP-плагина

  • Активация и деактивация не удаляют пользовательские данные неожиданно.
  • REST endpoint возвращает 403 для пользователя без прав и корректные данные для разрешённого.
  • Настройки сохраняются после очистки и не допускают опасной разметки.
  • Планировщик не создаёт дубли и убирает свои события.
  • Повторная операция не меняет результат непредсказуемо (идемпотентность).
  • Обновление старой версии сохраняет формат ключей и таблиц, если миграция не предусмотрена.

Регрессия перед релизом

Сначала убедитесь, что все запущенные тесты действительно завершились успешно. «Не запускалось» — это не «прошло». Отдельно документируйте результат ручной проверки в админке WordPress, мобильном браузере и на тестовой среде с реальной БД.

Куда двигаться дальше

Для тестов прав удобно взять пример собственного REST endpoint, а для тестирования настроек — Settings API. Отчёт о проверках храните вместе с исходным кодом и версией релиза.

Источник: https://make.wordpress.org/core/handbook/testing/automated-testing/writing-phpunit-tests/

Материал был полезен?

Помогите нам сделать материалы точнее и понятнее.