Мы все можем согласиться с тем, что 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.
Написание тестов для такой кодовой базы заставит вас подумать о том, как выглядит архитектура вашего кода, чтобы вы могли легко писать автоматические тесты, не говоря уже о времени и деньгах, которые вы сэкономите, поскольку вам не нужно все тестировать вручную.
