Автотесты Pest 2 через WP CLI как в Laravel

Мне нравится в Laravel запуск тестов, принципы автотесирования и еще начал изучать Pest для более элегантных и читаемых авто тестов. Пробуем интегрировать это все в WordPress & WP CLI.

Не сказать что я разобрался в этом на 100%, но некий базовый вариант решения уже есть.

Элегантность тестов Pest

Pest мне понравился тем что его код сильно проще чем у чистого PHPUnit.

Наверное его можно считать более современным, если сравнивать с популярным аналогом Jest – в среде JS сообщества.

test('тестируем функцию sum', function () {
   $result = sum(1, 2);
 
   $this->assertSame(3, $result); // Same as expect($result)->toBe(3)
});

Хорошее сравнение Pest & PHPUnit на примерах есть тут: https://medium.com/@antoine.lame/from-phpunit-to-pest-b825b1d881f3

Пробуем адаптировать запуск автотестов через WP CLI

В Laravel тоже есть такая обертка и тесты там запускаются так

php artisan test

Наш вариант будет работать так:

php wp pest

Пишем обертку для Pest & WP CLI. Называем ее Pest.php и кладем в wp-content/mu-plugins/Pest.php

/**
 * Pest wrapper for WP CLI
 *
 * Usage: wp pest
 */
add_action( 'cli_init', function(){
    WP_CLI::add_command( 'pest', function(){
        $files = glob(WP_CONTENT_DIR . '/*/*/pest/phpunit.xml');
        foreach($files as $file){
            $dir = plugin_dir_path($file);
            $pest_path = $dir . 'vendor/bin/pest';

            $command = sprintf('%s --configuration %s', $pest_path, $file);
            WP_CLI::log( 'Run command: ' . $command );
            echo shell_exec($command);
        }
    });
});

Тесты хранятся в компонентах

Текущее решение рассчитано на следующий контекст:

• тестируются только плагины и темы
• все составляющую находятся в подпапке pest – у темы или плагина
• внутри этой папки установка Pest происходит согласно официальной инструкции https://pestphp.com/docs/installation

Идею загрузки тестов по компонентам подсмотрел у этих ребят: https://github.com/akaunting/akaunting/blob/master/phpunit.xml

Разница только в том что обход модулей там сделан через XML конфиг, а в моем случае через Pest.php. В теории это можно улучшить. Но пока не придумал как это сделать просто.

Настраиваем bootstrap.php

Основная концепция этих тестов – интегральность. Мы тестируем фичи – а значит нам нужна загрузка всей системы, включая БД.

1. в phpunit.xml пишем bootstrap=”tests/bootstrap.php”
2. далее сам бутстрап у меня выглядит так:

require_once __DIR__ . '/../vendor/autoload.php';

define('WP_TESTS_CONFIG_FILE_PATH', __DIR__ . '/../../../../../wp-config.php');
define( 'WP_TESTS_DOMAIN', 'wooms.local' );
define( 'WP_TESTS_EMAIL', '[email protected]' );
define( 'WP_TESTS_TITLE', 'Test Blog' );

define( 'WP_PHP_BINARY', 'php' );

require_once WP_TESTS_CONFIG_FILE_PATH;

В этом случае происходит загрузка всей подсистемы.

Итого

В этом решении мне нравится семантика Pest – он имеет более понятный для человека язык, и стиль написания кода ближе к WP way.

Текущее решение уже хорошо работает для локальных тестов и TDD. Что для некоторых проектов уже большой шаг вперед.

Плюс удобство запуска из под WP CLI. Мелочь, но очень удобно.

Конечно нужно развивать это будет далее по ряду задач:

• сидинг и начальное наполнение БД
• возможность запуска тестов в CI/CD процессах
• развитие команд для автоматизации

Серия постов про авто тестирование в WordPress

Тестирование WordPress – авто тесты, unit, интеграционные, e2e/UI …

Есть такая особая тема в разработке – авто тесты. Юнит тесты, интеграционные, фича тесты, UI & e2e тесты. Одна из самых запутанных…