Pruebas.

DXPR Builder tiene cuatro tipos de comprobaciones automáticas: una prueba Puppeteer del editor, pruebas Bash de extremo a extremo para los comandos Drush, una suite Selenium de regresión visual en el repositorio separado dxpr_maven, y linters. Esta página enumera cada una, cómo ejecutarla en local y cómo la ejecuta CI.

Qué existe

La única prueba PHPUnit en el repositorio es modules/dxpr_builder_media/tests/src/FunctionalJavascript/MediaEntityBrowserTest.php para el submódulo de medios heredado. Ningún flujo de GitHub la ejecuta; el pipeline GitLab de drupal.org (.gitlab-ci.yml) usa las plantillas estándar DrupalCI, cuyo trabajo PHPUnit no está desactivado ahí.

Prueba de consola del editor

test/test-editor.js arranca un servidor estático en el puerto 3000 (test/start-standalone-server.js) y abre cuatro páginas independientes de test/standalone-editor/ en Chrome headless: test-bs5-anon.html, test-bs5-cms-block.html, test-bs5-editor.html y test-bs5-clean-html.html. Falla cuando:

• una página lanza un error JavaScript;
• el editor completo no está listo en 2000 ms, o quedan controles fuera de pantalla diferidos tras la carga (la puerta de rendimiento);
• los controles de elementos se solapan en modo Power user (la base es cero pares solapados);
• el HTML guardado de la página de editor completo es mayor que la referencia de 32.094 caracteres;
• falla una comprobación propia de una página, por ejemplo el análisis de HTML Bootstrap limpio, la miga de pan, los tipos de panel, el ajuste Muted de vídeo local o la vista previa de bloque CMS.

Las páginas cargan los archivos compilados desde dxpr_builder/, así que compila primero.

1. Instala dependencias:

   npm install
   

2. Compila el paquete del editor. El script CI ejecuta estas tareas en este orden (test/scripts/run-fe-tests.sh):

   npx grunt concat
   npx grunt exec:gen
   npx grunt babel
   npx grunt terser
   npx grunt sass
   npx grunt postcss
   

3. Ejecuta la prueba:

   npm run fe-test
   

   Usa npm run fe-test:headed para mirar el navegador, y npm run fe-test:dev para servir las páginas independientes sin ejecutar aserciones.

En CI, .github/workflows/fe-test.yaml ejecuta la misma prueba con Docker:

docker compose --profile fe-test run --rm fe-test

Pruebas Drush de extremo a extremo

scripts/drush-e2e/run-e2e-tests.sh instala un sitio Drupal 11 fresco con SQLite dentro de un contenedor Composer, enlaza el módulo en él, lo habilita, crea un tipo de contenido Basic page con el formato dxpr_builder_text, una plantilla de página y una plantilla de usuario, y luego ejecuta cada archivo scripts/drush-e2e/test-*.sh:

Ejecútalas todas:

docker compose --profile drush-e2e run --rm e2e-test

Ejecuta un archivo pasando parte de su nombre; el script coincide con scripts/drush-e2e/test-*<filter>*.sh:

docker compose --profile drush-e2e run --rm e2e-test page-create

Para añadir una prueba, crea scripts/drush-e2e/test-<name>.sh, llama a section "<Title>", y usa las ayudas de scripts/drush-e2e/_helpers.sh: assert_success, assert_fail, assert_eq, assert_has, assert_not_empty, assert_runs y assert_dry_run. Cada ayuda toma una descripción y una cadena de comando.

En CI esta suite es el trabajo "Run Drush E2E tests" en .github/workflows/review.yaml. Se ejecuta cuando un pull request cambia archivos .php, .module, .inc, .install, .yml, .md, composer.json o composer.lock.

Suite Selenium de regresión visual

Las pruebas de navegador son suites Java TestNG en el repositorio dxpr_maven. Se ejecutan contra una pila Docker definida en docker-compose.test.yml (hub Selenium, nodos Chrome y un contenedor Maven) en un sitio instalado desde este repositorio. No las ejecutas desde una copia local; las activas desde un comentario en un pull request. .github/workflows/command-dispatcher.yml convierte el comentario en una ejecución de flujo.

Opciones, como se documenta en CONTRIBUTING.md:

• groups=row-element-test,icon-element-test ejecuta los grupos <test name="..."> nombrados desde el XML de la suite.
• tests=RowColumnLayoutVisualTest ejecuta las clases de pruebas nombradas.
• maven_ref=branch-name usa una rama dxpr_maven, que es como un cambio del constructor y su actualización de pruebas se revisan juntos.

El flujo sube target/reports/** y las capturas como artefacto de compilación y publica el resultado como comentario en el pull request, enumerando fallos o pruebas que solo pasaron al reintentar. Cada trabajo de suite tiene un tiempo de espera de 90 minutos.

Linters y análisis estático

Cada linter es un servicio Docker Compose, así que no se necesita cadena de herramientas local más allá de Docker.

Existen variantes de corrección automática para phpcs, ESLint y Stylelint (drupal-lint-auto-fix, eslint-auto-fix, stylelint-auto-fix). Las mismas comprobaciones están disponibles sin Docker con npm run lint:scss, npm run lint:no-jquery, npm run lint:no-underscore y npm run lint:html-in-js.

npm install también instala un hook pre-commit de Husky (.husky/pre-commit). Ejecuta los servicios de corrección automática y lint coincidentes en los archivos JavaScript, PHP y SCSS en staging y los fuentes Rust, y docs/video-tools/bin/lint-videos.mjs cuando archivos en docs/ están en staging.

.github/workflows/review.yaml ejecuta los linters que coinciden con las rutas cambiadas en cada pull request. .github/workflows/main.yaml ejecuta drupal-lint, eslint, drupal-check-D11 y rust-lint en cada push a 3.x. Ambos fallan la compilación cuando falla una comprobación y escriben un resumen con los archivos infractores.

¿Qué sigue?

• Cómo contribuir para el proceso de pull request y el flujo maven_ref para actualizaciones de pruebas.
• Comandos Drush para los comandos que la suite Bash ejercita.