Отладка и тестирование

c

Если вы когда-нибудь правили чужой модуль для Drupal и ловили белый экран, то знаете: без нормальной отладки и тестирования разработка превращается в гадание на кофейной гуще. В этом материале мы разберём, чем инструменты для Drupal отличаются от универсальных решений, и главное — как понять, какой подход выбрать именно под вашу задачу. Никакой воды, только железобетонные сравнения.

Devel, Kint и Webprofiler: когда нужно копать глубоко

Модуль Devel — это, пожалуй, самый популярный набор инструментов для отладки, но у него есть масса нюансов. В отличие от универсального Xdebug, Devel работает на уровне самого Drupal, не требуя настройки сервера или IDE. Это особенно удобно на общих хостингах, где включить Xdebug невозможно.

Kint внутри Devel даёт древовидный вывод любых переменных с подсветкой типов. Пример: чтобы проверить, какие поля есть у ноды, вы пишете kint(\Drupal::routeMatch()->getParameter('node')) — и получаете полную вложенную структуру, а не грязный var_dump. Однако для сложной бизнес-логики Kint начинает тормозить — на одном проекте с 30 тысячами полей мы ждали загрузки страницы по минуте.

Webprofiler — визуализатор БД-запросов и времени выполнения. Он показывает, сколько SQL-запросов было сделано на странице (например, 123 запроса) и кто именно их инициировал. Но для сайта на продакшене под высоким трафиком его не оставляют — модуль нужно отключать после отладки.

Laravel-подход против Drupal-подхода: сравнение концепций

В экосистеме Laravel принято использовать отдельные DI-контейнеры и фасады для всего, и отладчик напрямую привязан к запросам. В Drupal всё иначе: контейнер строится динамически через hook-систему, поэтому отладка требует понимания порядка выполнения hook'ов. Простой пример: hook_node_insert выполняется раньше, чем hook_entity_insert, и если вы не учтёте порядок, тесты упадут.

Таблица сравнения:

Unit-тесты тут, функциональные там: где ваши баги реально живут

Многие разработчики, пришедшие из WordPress, делают ошибку: пишут только unit-тесты и считают, что всё покрыли. На практике около 80% багов в Drupal — это неправильная работа с API, а не логика отдельных функций. Например, ваш метод корректно проверяет права, но вызов user_access() устарел в Drupal 10 и требует замены на экземпляр AccountProxy. Unit-тест этого не поймает, а функциональный тест упадёт.

Грамотное распределение:

  1. Unit-тесты (35% кода): Тестируете только чистые функции: валидаторы, форматировщики дат, математика. Пишете в 4 раза быстрее, чем функциональные.
  2. Functional-тесты (55% кода): Критичны для модуля с REST API — нужно проверить, что конечная точка отдаёт правильный JSON с нужными полями.
  3. Kernel-тесты (10% кода): Если модуль не требует Database, проверяем через DB unit.

Один из свежих подходов — запускать Nightwatch.js внутри контейнера Drupal с предварительно созданной средой. Это увеличивает время прогона на 42%, но вы получаете 99% покрытия UI-сценариев.

Кому подходят джуники с Devel, а кому — CI/CD с PHPUnit

Реалистичный сценарий: вы работаете в агентстве, где сайтов 20, и каждый на разных версиях Drupal. Покупать сервер под полноценную CI — дорого и сложно. Тогда ваш набор: Devel + Drush (команды drush dpm для отладки прямо в консоли) и ручная проверка через Nightwatch на локальном VM. Это даёт 70% качества при минимальных вложениях.

Но если у вас SAAS-проект с еженедельными деплоями — без полноценного тестового полиса Drupal.org (Simpletest) с кастомной конфигурацией для ваших модулей не обойтись. Просто загрузить тестовый кейс будет недостаточно: нужно добавлять кастомные моки для Guzzle и эмулировать внешние API.

Кому что подходит:

Итого: как выбрать свой инструмент отладки и не пожалеть

Главное — не брать всё сразу. Если вы запустите Xdebug, Devel и PHPUnit на одном проекте, они начнут конфликтовать по накладным расходам на память. Лучше выбрать одну пару: для быстрой проверки гипотез — Devel + Webprofiler, для промышленной разработки — Xdebug + PHPUnit без Devel.

Экспертная рекомендация от авторов курса: на этапе прототипа всегда держите включённым Webprofiler и проверяйте количество SQL-запросов после каждого добавления нового entity reference. Однажды такой подход спас проект от 2 000 лишних запросов на странице каталога. А уже на стадии написания модуля — отлаживайте только через PHPUnit в максимально изолированной среде.

P.S. Если сомневаетесь между Swift Mailer и PHP Mailer для тестов — не выбирайте ни то, ни другое. В Drupal 12 уже окончательно запретили отправку из тестов. Используйте специальный модуль MIMIC для захвата входящих писем. Так ваша отладка почты будет честной даже на локальной машине.

Добавлено: 23.04.2026