Введение

Это было трудно и больно, но у меня есть очень веские причины, чтобы написать тест-драпаль. В течение многих лет я говорил, что тестирование превосходит сильные типы (тот же аргумент, который они используют для продвижения шрифта, должен использоваться для продвижения TDD, а тестирование - гораздо более высокое мышление). Чтобы быть верным своему слову, я использую тестовую разработку (TDD) в каждом стеке: Ruby, front-end javascript, php и, наконец, python. Разработчики Drupal некоторое время писали тесты и использовали расширенные интеграционные тесты. В этой статье я расскажу о создании среды тестирования и проведении единого теста ядра.

Недавно я перешел с Drupal 9 на Drupal 10, и мне пришлось изменить все версии. Я вообще не рекомендую: я рекомендую с комфортом остановиться на старой версии. Drupal 10 толще и медленнее, чем Drupal 9, и я фактически потерял функциональность после обновления. Поэтому я прекратил миграцию своей экосистемы и буду поддерживать неиммиграционные сайты Drupal на версии 9, пока могу. Я также буду поддерживать drupal 10 сайтов без возврата, потому что для возврата потребуется выполнить работу, чтобы вернуться назад.

Я думаю, что основная мотивация и слова поддержки для начинающих / промежуточных разработчиков Drupal, которые хотят включить тестирование, заключается в том, что оно работает. Если вы чувствуете разочарование всеми движущимися частями и несколько нелогичную настройку, я хочу сказать, иметь веру в то, что вы можете заставить это работать, проблемы могут быть решены, и это действительно начинает работать через некоторое время.

А теперь о технической части.

Разрешение зависимостей

Я застрял в нескольких несоответствиях версий! Ошибка, которая печатает, является какой-то неясной, неисследуемой ошибкой, и для ее исправления мне пришлось сопоставить версии нескольких пакетов. Вы должны указать версии, кажется, что композитор не сделает для вас хорошую работу. Дерево зависимостей не очевидно: версия 10.6 * требует * версии 7.4 в другом месте. Я не знаю ваших точных версий, и вы можете попросить GPT или иным образом убедиться, что ваши версии верны. Мне также пришлось понизить рейтинг двух несвязанных модулей: «symfony/css-selector»: «^6.4» и «symfony/dom-crawler»: «^6.4».

composer require --dev drupal/core-dev:10.6.12 -W
composer require --dev symfony/phpunit-bridge:^7.3 ## drupal 10.6
composer require --dev phpunit/phpunit
composer require --dev behat/mink

В конце концов, мои версии сработали.

Затем я попросил GPT написать минимальный тест. Мы будем использовать это вместо моих реальных тестов.

<?php
// file $MODULE_ROOT/tests/src/Kernel/SanityTest.php
namespace Drupal\Tests\ish_drupal_module\Kernel;
use Drupal\KernelTests\KernelTestBase;
class SanityTest extends KernelTestBase {
 protected static $modules = [ 'system' ];
 public function testTrue(): void {
   $this->assertTrue(TRUE);
 }
}

А теперь попробуем провести этот тест.

Проводка тестового приложения

Теперь интересный и важный вопрос заключается в том, как настроить среду тестирования для модуля. Я развертываю модуль с композитором внутри докера, поэтому развертывание производства включает в себя (1) ударную версию в composer.json и (2) запуск «композитор требует вася-ко/иш drupal module». Очевидно, что это не тестовая среда, поэтому необходимо добавить хорошую тестовую упряжку. Я решил адаптировать стратегию из экосистемы Ruby-on-rails. Я упаковываю минимальное приложение drupal через докер внутри модуля, хотя ожидается, что модуль будет жить в другой производственной среде. Таким образом, модуль имеет собственное приложение только для тестирования, что делает его самодостаточным для тестирования и не зависит от другого проекта.

Вы можете увидеть фактическую проводку моего модуля, потому что он с открытым исходным кодом: https://github.com/wasya-co/ish drupal module

Я копировал файл docker-compose.yml с производства. Важное изменение заключается в том, чтобы не использовать объемы, а вместо этого использовать объемы связывания.

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

Как только я запущу контейнер, я могу войти:

./scripts/login test

Проведите тест в контейнере:

composer install
export SIMPLETEST_DB="mysql://root:test1234@mysql/ish_drupal_module_test"
export SIMPLETEST_BASE_URL="http://127.0.0.1"
./vendor/bin/phpunit \
 -c /var/www/html/web/core/phpunit.xml.dist \
 web/modules/custom/ish_drupal_module/tests/src/Kernel/SanityTest.php

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

И вуаля! Мы в бизнесе.