Как начать тестирование кода 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.

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

Если вы считаете, что это может вам пригодиться, не стесняйтесь использовать его и пометить репозиторий на GitHub.

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