Introducción

Ha sido difícil y doloroso, pero tengo muy buenas razones para escribir drupal impulsado por pruebas. Durante años he estado diciendo que la prueba es superior a los tipos fuertes (el mismo argumento que usan para promover el tiposcript, debe ser utilizado para promover TDD en su lugar, y la prueba es una mentalidad muy superior). Para ser fiel a mi palabra empleo el desarrollo basado en pruebas (TDD) en cada pila: ruby, front-end javascript, php y finalmente python. Mientras que algo difícil, los desarrolladores de Drupal han estado escribiendo pruebas por un tiempo, y utilizar pruebas de integración avanzadas. En este artículo, voy a hablar de establecer el entorno de pruebas y ejecutar una única prueba de kernel.

Recientemente realicé de Drupal 9 a Drupal 10 y tuve que cambiar versiones de todo. Generalmente no lo recomiendo: recomiendo estar cómodamente en la versión antigua. Drupal 10 es más gordo y más lento que Drupal 9, y en realidad *perdí* funcionalidad después de la actualización, y no ganó ninguna nueva funcionalidad. Por lo tanto, detuve la migración de mi ecosistema y mantendré los sitios de ruptura no migrados en la versión 9, mientras que puedo. Mantendré los 10 sitios drupales además sin revertir - porque revertir me requeriría hacer trabajo para retroceder - algo que no puedo recomendar.

Supongo que la principal motivación y palabras de aliento que tengo para desarrolladores drupales principiantes/intermedios que buscan incorporar pruebas es, que funciona. Si usted se siente frustrado con todas las partes móviles y una configuración algo contraintuitiva, quiero decir, tener fe de que usted puede hacer que funcione, los problemas se pueden resolver, y comienza a trabajar después de un tiempo.

Y ahora por la parte técnica.

Dependencias de solución

¡Me atasqué con múltiples desajustes de la versión! El error que imprime es un error oscuro e inescrutable, y para corregirlo tuve que buscar varios paquetes. Usted *tiene que* especificar versiones, parece que el compositor no hará un buen trabajo para usted. El árbol de dependencia no es obvio: la versión 10.6 *requiere* versión 7.4 en otro lugar. No sé sus versiones exactas, y puede preguntar a GPT o asegurarse de que sus versiones sean correctas. También tuve que reducir dos módulos no relacionados: "symfony/css-selector": "^6.4" y "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

Eventualmente, mis versiones funcionaron.

Entonces le pedí a GPT que escribiera una prueba mínima. Usaremos esa en lugar de mis pruebas reales.

<?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);
 }
}

Y ahora intentemos hacer este examen.

Wiring the Testing App

Ahora, una pregunta interesante e importante es cómo configurar el entorno de pruebas para el módulo. Despliegue el módulo con el compositor dentro del docker, por lo que el despliegue de la producción incluye (1) parar la versión en composer.json y (2) ejecutando `compositor requieren wasya-co/ish drupal module`. Esto obviamente no es un ambiente de prueba, y por lo tanto hay que añadir un buen arnés de prueba. Decidí adaptar una estrategia del ecosistema de rubí sobre peligros. Empaqué una aplicación mínima drupal, vía docker, dentro del módulo, aunque se espera que el módulo viva dentro de otro entorno de producción. De esta manera, el módulo lleva su propia aplicación, sólo para la prueba, lo que la hace autosuficiente para la prueba, y no depende de otro proyecto.

Puedes ver el cableado real de mi módulo porque es de código abierto: https://github.com/wasya-co/ish drupal module

He copiado el archivo docker-compose.yml de la producción. El cambio importante es no utilizar volúmenes, y utilizar volúmenes de bind en su lugar.

No tiene que ser una aplicación funcional, ya que sólo la uso para pruebas. Si quieres que sea una aplicación que funcione, por favor dame un mensaje.

Una vez que empiezo el contenedor, puedo iniciar sesión:

./scripts/login test

Y realizar una prueba en el contenedor:

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

De nuevo, note que la prueba está encapsulada dentro del módulo, como debe ser. No se requiere código externo para ejecutarlo.

¡Y voila! Estamos en el negocio.