Тестирование WordPress – авто тесты, unit, интеграционные, e2e/UI …

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

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

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

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

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

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

Авто тесты

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

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

  • делать тесты руками сложно, дорого и хрупко.
  • потому команды придумывают разные подходы к автоматизации тестирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры:

UI тесты или e2e

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

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

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

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

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

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

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

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

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

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

Кент Си Доддс

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

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

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

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

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

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

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

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

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

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

Итого

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

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

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

Автотесты Pest 2 через WP CLI как в Laravel

Мне нравится в Laravel запуск тестов, принципы автотесирования и еще начал изучать Pest для более элегантных и читаемых авто тестов. Пробуем интегрировать…

Ответить

Ваш адрес email не будет опубликован. Обязательные поля помечены *