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

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

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

Разберемся какие тут встречаются понятия:

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

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

Авто тесты

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

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

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

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

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

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

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

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

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

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

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

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

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

• HA https://github.com/hybridauth/hybridauth/tree/master/tests
• Guzzle https://packagist.org/packages/guzzlehttp/guzzle
• Faker https://github.com/fzaninotto/Faker/tree/master/test

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

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

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

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

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

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

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

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

Потому важно понимать, что если вы пишите приложение, с конкретной конфигурацией и БД, и не пишите модуль под все фреймворки, то писать модульные юнит тесты — это идиотизм.

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

Примеры:

• Akaunting — пишут только интегральные фича тесты https://github.com/akaunting/akaunting/tree/master/tests
• WordPress — пишут только интеграционные тесты и чуть чуть юнитов https://buddy.works/guides/wordpress-unit-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/

Итого

Важно понимать что в этом мире не все всегда и везде, а кое что иногда и местами.

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

Беда с WordPress — из коробки ничего нет. А большинство тех которые считаются умными — используют юниты. Тем самым просто пытаясь забивать гвозди микроскопом.

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

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

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