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

На распутывание этой истории у меня ушло много лет 🙂

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

Авто тесты и TDD в WordPress на базе плагина Testeroid

Тут встречаются разные умные слова и понятия:

пирамида тестов: юниты, интеграционные и e2e
авто тесты
фича тесты
UI тесты
модульные тесты
ручные тесты
смок тесты
регрессионные тесты

Давайте разбираться во всем этом многообразии зоопарка в контексте PHP & WordPress…

Авто тесты

Итак лучше начать с самого общего понятия – авто тесты. Что это такое?

Простыми словами:

делать тесты руками сложно, дорого и хрупко.

потому команды придумывают разные подходы к автоматизации тестирования.

Пока все просто? Да 🙂

Модульные или unit тесты

Очень много кодеров думают что это база всего. Типа надо начинать с юнит тестов. Потому что они самые быстрые.

Да действительно юнит тесты самые быстрые. Мы тестируем просто код, без подключения БД или внешних систем. Мы просто проверяем простые функции и методы на предмет их работы.

Но вот давайте подумаем – о чем нам говорит фраза модульные тесты?

Когда мы можем реально проверять только код и быть уверены что это хорошо?

Ответ в самой фразе – когда мы пишем модули.

А точнее компоненты, типа пакеты, библиотеки или что то такое, что работает на разных платформах или фреймворках.

Такие проекты не должны быть зависимы от фреймворков, платформ или используемой БД. Они должны работать одинаково хорошо для Laravel, Symfony, WordPress или даже на чистом PHP. И с любой БД конечно же…

Примеров куча

Все это модули для PHP, которые должны работать на любом фреймворке и с любой БД.

Ну и конечно же юнит тесты для таких модулей – это лучше всего.

Интегральные, интеграционные или фича тесты

Тут интересней. Многие думают что интеграционные тесты это дорого и сложно. А так ли оно на самом деле?

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

Еще раз – речь не про модули, речь про то что мы тестируем не просто какую то библиотеку, пакет или модуль – мы тестируем приложение в целом. С учетом всех составляющих.

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

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

Когда мы пишем конкретный продукт, с конкретной платформой, БД, и бизнес логикой – обычно и проще всего это все тестировать только через интеграционные тесты.

Примеры:

Akaunting – пишут только интегральные фича тесты https://github.com/akaunting/akaunting/tree/master/tests
WordPress – пишут в основном интеграционные тесты и чуть чуть юнитов https://github.com/WordPress/wordpress-develop/tree/trunk/tests/phpunit/tests/
FreeScout – вообще тесты не пишут, но рвут конкурентов в клочья https://github.com/freescout-helpdesk/freescout/tree/dist/tests

UI тесты или e2e

Далее вступают в игру тесты через браузер. Типа тесты с точки зрения конечного пользователя.

В моем понимании это самый простой тип тестов и каких то особых проблем тут я не встречал.

Инструменты разные на любой вкус:

если Laravel то стандарт это Dust
у WordPress это WP Browser
а есть еще классика типа Selenium и Cypress

Борьба пирамиды с вазой

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

В целом понять джунов можно – они ничего слаще морковок не ели и в целом опыта у них мало.

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

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

Чем ваши тесты больше похожи на то, как приложение используют, тем больше полезности и уверенности они вам принесут.
Кент Си Доддс

Чуть больше деталей тут: https://habr.com/ru/company/samokat_tech/blog/704342/

Проблема авто тестов в WordPress

Если брать эко систему Laravel – то там все просто, хорошие авто тесты идут из коробки и фокус на интегральных фича тестах.

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

Беда с WordPress – из коробки ничего нет. Чаще всего приходится изобретать что то с нуля. И большинство тех которые пытаются что то тестировать – используют юниты. Потому что так пишут в этих ваших Интернетах.

И даже если этим ребятам попытаться объяснить что юниты это для модулей, а не для приложений, привести примеры – не помогает. У человека в голове уже висят юнит тесты, и он не видит ничего иного.

Тем самым такие инженеры велосипедов с костылями просто пытаются забивать гвозди микроскопом.

Слишком сильна инерция шаблонного мышления и отсутствия способности думать головой.

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

Изучать то как тестируется ядро WP https://github.com/WordPress/wordpress-develop/tree/trunk/tests (реальные проекты тестируются примерно также)
Изучить конструктор авто тестов для плагинов https://developer.wordpress.org/cli/commands/scaffold/plugin-tests/

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

Итого

Важно изучать факты, идти от общего к частному, смотреть на лучшие мировые практики, понимать разницу между тестированием модулей и приложений. И тогда ваши авто тесты будут эффективными.

P.S. Если есть кто то с опытом авто тестов в WP, на реальных проектах, пишите в комментах как у вас. Оч интересно 🙂

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