Я разработчик плагинов, абсолютно не имеющий опыта работы в отрасли. Я создал простой плагин, чтобы добавить нескольких участников в сообщение через метабокс.
Я искал тонны веб-сайтов, и я узнал, что мне нужны wp-cli и PHPUnit для выполнения Unit Tests, но я не знаю, что тестировать, какие функции / крючки включать или исключать для тестирования, какие меры предосторожности мне нужно принимать и как для подачи фиктивных пользовательских данных на тест.
Может ли кто-нибудь здесь вести меня через этот процесс?
Во-первых, обратите внимание, что «модульное тестирование» в WordPress обычно выходит за рамки модульного тестирования и больше похоже на функциональное / интеграционное тестирование. Это скорее техническая разница, но если вы понимаете разницу между этими разными вещами, вас иногда можно смутить тем, как «единица» WordPress проверяет вещи.
Когда вы спрашиваете, какие части плагина вы должны тестировать, в идеале вы должны тестировать все это. Но что касается частей, которые вы должны выполнить (или интеграции), и какие части вы должны использовать приемочные испытания, это другое дело.
В настоящее время для моих плагинов я использую два разных уровня тестов: «единичные» тесты с PHPUnit, а приемочные тесты запускаются в браузере через WP Browser . Модуль тестирует внутреннюю логику, тогда как приемочные тесты проверяют, что, когда пользователь использует ваш интерфейс плагина, он действительно работает.
К модульным тестам относятся:
В принципе, любая функция, с которой вы передаете значение (ы), и делает с ней что-то подобное, и / или возвращает вам какое-то значение.
Чтобы протестировать этот тип кода, вы пишете тест, который вызывает функцию, о которой идет речь, передавая определенные значения, а затем утверждаете, что возвращаемый результат – это то, что вы ожидаете. Или, для функций, которые изменяют базу данных, вы утверждаете, что база данных содержит значения, которые ожидаются после вызова функции.
Код, который сложно тестировать в блоке, а некоторые, возможно, утверждают, что он не должен тестироваться на модуле, будет кодом, который в основном просто предназначен для вывода информации в браузер. Вот тогда и будут проходить приемочные испытания.
Кроме того, поскольку вы упоминаете действия / фильтры, похоже, что вам может быть интересно, следует ли вам проверять, что функция подключена к правильному действию, или что функция, которую вы подключили к фильтру, фактически применяется, когда WordPress вызывает этот фильтр. Это может потребоваться или не понадобиться, в зависимости от действия или фильтра. Как правило, я не тестирую такого рода вещи, поскольку обычно это то, что лучше подходит для функциональных / приемочных испытаний (хотя приемочные тесты проверяют их косвенно).
Таким образом, в основном, логика модульного теста и методы базы данных, приемочные испытания действительного интерфейса пользователя вашего плагина. Для того, чтобы это хорошо работало, конечно, вам нужно, чтобы ваш код шаблона / вывода в основном был отделен от вашей другой логики, что в целом является хорошей идеей.
В вашем случае вы можете обнаружить, что приемочные тесты действительно более полезны для вашего плагина, а модульные тесты действительно не нужны, поскольку большинство из них уже будет проверено приемочными испытаниями. Однако, как правило, оба идеала.
Я бы сказал, что в случае WordPress модульные тесты – это не единственное, на что стоит обратить внимание: функциональные / интеграционные / приемочные тесты (вы выбираете типы, которые более актуальны в вашей ситуации) также важны, в основном, для потому что это экосистема, и важно убедиться, что ваш код работает с остальными компонентами (и в качестве бонуса даже с некоторыми из основных плагинов, таких как WooCommerce, Yoast SEO и т. д.).
Для всех вышеперечисленных (включая модульные тесты, но не обязательные), я лично обнаружил, что Codeception является простым инструментом для начала работы. Luca делает важную работу, связанную с WordPress в этой области, с расширением wp-браузера для Codeception, между прочим. У него также есть отличный блог, объясняющий многое.