Как начать тестирование кода WordPress с помощью Pest PHP Testing Framework

Мы все можем согласиться с тем, что WordPress прошел долгий путь с момента своего появления и превратился в нечто большее, чем просто программное обеспечение для ведения блогов.

По своей сути это все еще система управления контентом (CMS), но с более чем 59 000 плагинов в каталоге wordpress.org вы можете настроить ее намного больше.

Причиной его популярности является низкий порог входа как для создателей контента, так и для разработчиков. Иногда за это приходится платить. Не секрет, что у WordPress плохая репутация, когда дело доходит до разработки. У него много устаревшего багажа и несгибаемых правил, которые предотвращают любые изменения, нарушающие обратную совместимость, когда дело доходит до PHP-кода (Гутенберг — это еще одна история, в которую я не буду вдаваться).

Этот устаревший код PHP часто используется разработчиками, которые только начинают входить в мир программирования, и проблема в том, что они могут изучить некоторые плохие шаблоны программирования. Это, в свою очередь, означает, что они будут повторно использовать плохо написанный код, увеличивая количество плохого кода в мире.

Именно здесь WordPress получает плохую репутацию в сообществе разработчиков.

Разорвать цикл

Итак, как мы можем разорвать этот цикл плохого кода? Обучая новых разработчиков тому, как писать хороший код. Одним из примеров обучения новых разработчиков (но также и старых, которые все еще цепляются за способ ведения дел «WordPress») является написание руководств.

Другой способ — побудить их использовать инструменты, которые помогут им писать более качественный код.

В настоящее время я участвую в работе, целью которой является выпуск новой версии стандартов кодирования WordPress , набора правил, используемых для инструмента PHP_CodeSniffer , который позволит вам узнать, есть ли в вашем коде какие-либо потенциальные проблемы (безопасность, лучшие практики, стиль кода). ).

Другой инструмент, который я недавно разработал, — это пакет , который поможет разработчикам настроить интеграционные тесты WordPress, использующие среду тестирования Pest .

Итак, зачем нам нужен этот новый инструмент?

Основная мотивация создания этого пакета — побудить больше людей писать тесты для своего кода, особенно разработчиков плагинов.

Многие разработчики в сообществе WordPress придерживаются мантры: я вижу, что это работает, потому что я пробовал это в своем браузере. Это нормально, но с этим есть проблемы.

Во-первых, это отнимает много времени. Каждый раз, когда вы вносите какие-то изменения, вы должны убедиться, что они работают, а также что вы ничего не сломали.

Во-вторых, люди ошибаются. Мы не застрахованы от ошибок, и код может быть использован не по назначению способами, о которых вы и не подозревали. Вы будете поражены тем, насколько креативными могут быть люди при написании кода.

Автоматические тесты выполняются быстро и могут помочь вам в тестировании различных случаев, которые произойдут при выполнении вашего кода.

Вы тестируете предполагаемое поведение (успешный путь) и быстро добавляете примеры того, как ваш код можно использовать не так, как вы предполагали (неудачный путь).

Это также защищает ваш код от регрессии. Регрессия кода — это когда вы непреднамеренно ломаете одну часть своего кода, добавляя новый код.

Проблема с тестами настроена до сих пор

Тестирование в WordPress — вещь не новая. И не то чтобы раньше вы не могли настроить тесты для своего кода. Есть замечательные библиотеки, которые помогут вам настроить все, например, wp-browser .

Но проблема в том, что процедура установки часто неуклюжа.

Вам нужно настроить отдельную базу данных для тестов, и вам нужно запустить определенные скрипты, а затем изменить файлы, чтобы все это заработало.

Посмотрим правде в глаза, это не так просто сделать, и разработчики по своей природе ленивые существа (вот почему мы пишем код, который делает что-то за нас ).

Цель настройки интеграционного теста wp-pest — устранить всю эту дополнительную работу.

Как это настроить

Чтобы настроить его, ваш проект должен использовать Composer . Это де-факто стандартный способ добавления пакетов в ваш код.

В вашем типе терминала

composer require dingo-d/wp-pest-integration-test-setup –dev

После того, как вы загрузили пакет и его зависимости, вы можете настроить тесты темы, набрав

vendor/bin/wp-pest setup theme

Или, если вы хотите настроить тесты для своего плагина, вы можете написать

vendor/bin/wp-pest setup plugin –plugin-slug=your-plugin-slug

При желании вы можете –wp-versionуказать параметр, чтобы указать, на какой версии WordPress вы хотите протестировать свой код.

В фоновом режиме будет загружен экземпляр WordPress и настроена база данных в памяти, а также два примера тестов, которые вы можете запустить.

Затем, запустив либо

vendor/bin/pest –group=unit

или

vendor/bin/pest –group=integration

проведу тесты.

Прелесть Pest в том, что его синтаксис удобен для разработчиков. У него потрясающая документация и отличный синтаксис. Давайте рассмотрим простой пример. Допустим, вы регистрируете пользовательский тип записей под названием «Книги»:

<?php

/**
* Plugin Name: Test plugin
* Desctiption: Test plugin
* Version: 1.0.0
* License: MIT
*/

function test_plugin_register_books_cpt() {
$args = array(
‘label’ => esc_html__( ‘Books’, ‘test-plugin’ ),
‘public’ => true,
‘publicly_queryable’ => true,
‘show_ui’ => true,
‘show_in_menu’ => true,
‘query_var’ => true,
‘rewrite’ => array( ‘slug’ => ‘book’ ),
‘capability_type’ => ‘post’,
‘has_archive’ => true,
‘hierarchical’ => false,
‘menu_position’ => null,
‘supports’ => array( ‘title’, ‘editor’, ‘author’, ‘thumbnail’, ‘excerpt’, ‘comments’ ),
);

register_post_type( ‘book’, $args );
}

add_action( ‘init’, ‘test_plugin_register_books_cpt’ );

После запуска команды установки, которая добавляет пример, вызванный тест BooksCptTest.phpбудет выглядеть так:

<?php

namespace Tests\Integration;

beforeEach(function () {
parent::setUp();
});

afterEach(function () {
parent::tearDown();
});

test(‘Books custom post type is registered’, function () {
// We can use assertions from PHP_Unit.
$this->assertNotFalse(has_action(‘init’, ‘test_plugin_register_books_cpt’));

$registeredPostTypes = \get_post_types();

// Or we can use expectations API from Pest.
expect($registeredPostTypes)
->toBeArray()
->toHaveKey(‘book’);
});

Запуск vendor/bin/pest –group=integrationдает нам следующий вывод:

Installing…
Running as single site… To run multisite, use -c tests/phpunit/multisite.xml
Not running ajax tests. To execute these, use –group ajax.
Not running ms-files tests. To execute these, use –group ms-files.
Not running external-http tests. To execute these, use –group external-http.

PASS Tests\\Integration\\BooksCptTest
✓ Books custom post type is registered

Tests: 1 passed
Time: 0.14s
Вывод

Точно так же у вас есть возможность запускать интеграционные тесты WordPress в своей теме или плагине. Тесты удивительны, потому что они не только защищают нас от ошибок, но и заставляют нас писать чистый и тестируемый код. Это особенно актуально для плагинов со сложной логикой или взаимодействующих со сторонними API.

Написание тестов для такой кодовой базы заставит вас подумать о том, как выглядит архитектура вашего кода, чтобы вы могли легко писать автоматические тесты, не говоря уже о времени и деньгах, которые вы сэкономите, поскольку вам не нужно все тестировать вручную.