Tests.

DXPR Builder a quatre sortes de vérifications automatisées : un test Puppeteer de l’éditeur, des tests Bash de bout en bout pour les commandes Drush, une suite Selenium de régression visuelle dans le dépôt séparé dxpr_maven, et des linters. Cette page liste chacun, comment l’exécuter en local et comment la CI l’exécute.

Ce qui existe

L’unique test PHPUnit du dépôt est modules/dxpr_builder_media/tests/src/FunctionalJavascript/MediaEntityBrowserTest.php pour le sous-module média hérité. Aucun workflow GitHub ne l’exécute ; le pipeline GitLab de drupal.org (.gitlab-ci.yml) utilise les modèles DrupalCI standard, dont le job PHPUnit n’y est pas désactivé.

Test console de l’éditeur

test/test-editor.js démarre un serveur statique sur le port 3000 (test/start-standalone-server.js) et ouvre quatre pages autonomes depuis test/standalone-editor/ en Chrome headless : test-bs5-anon.html, test-bs5-cms-block.html, test-bs5-editor.html et test-bs5-clean-html.html. Il échoue quand :

• une page lance une erreur JavaScript ;
• l’éditeur complet n’est pas prêt sous 2000 ms, ou des contrôles hors écran restent différés après chargement (la barrière de performance) ;
• des contrôles d’éléments se chevauchent en mode Power user (la référence est zéro paire qui se chevauche) ;
• le HTML enregistré de la page complète de l’éditeur dépasse la référence de 32 094 caractères ;
• une vérification propre à une page échoue, par exemple l’analyse du HTML Bootstrap propre, le fil d’Ariane, les types de panneaux, le réglage Muted de la vidéo locale ou l’aperçu du bloc CMS.

Les pages chargent les fichiers construits depuis dxpr_builder/, donc construisez d’abord.

1. Installez les dépendances :

   npm install
   

2. Construisez le paquet de l’éditeur. Le script CI exécute ces tâches dans cet ordre (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. Exécutez le test :

   npm run fe-test
   

   Utilisez npm run fe-test:headed pour regarder le navigateur, et npm run fe-test:dev pour servir les pages autonomes sans exécuter les assertions.

Dans la CI, .github/workflows/fe-test.yaml exécute le même test via Docker :

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

Tests Drush de bout en bout

scripts/drush-e2e/run-e2e-tests.sh installe un site Drupal 11 frais avec SQLite dans un conteneur Composer, y lie le module en lien symbolique, l’active, crée un type de contenu Basic page avec le formateur dxpr_builder_text, un modèle de page et un modèle d’utilisateur, puis exécute chaque fichier scripts/drush-e2e/test-*.sh :

Exécutez-les tous :

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

Exécutez un fichier en passant une partie de son nom ; le script correspond à scripts/drush-e2e/test-*<filter>*.sh :

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

Pour ajouter un test, créez scripts/drush-e2e/test-<name>.sh, appelez section "<Title>", et utilisez les utilitaires de scripts/drush-e2e/_helpers.sh : assert_success, assert_fail, assert_eq, assert_has, assert_not_empty, assert_runs et assert_dry_run. Chaque utilitaire prend une description et une chaîne de commande.

Dans la CI, cette suite est le job « Run Drush E2E tests » dans .github/workflows/review.yaml. Elle tourne quand une pull request change des fichiers .php, .module, .inc, .install, .yml, .md, composer.json ou composer.lock.

Suite Selenium de régression visuelle

Les tests navigateur sont des suites Java TestNG dans le dépôt dxpr_maven. Elles tournent contre une stack Docker définie dans docker-compose.test.yml (hub Selenium, nœuds Chrome et un conteneur Maven) sur un site installé depuis ce dépôt. Vous ne les exécutez pas depuis une extraction locale ; vous les déclenchez depuis un commentaire de pull request. .github/workflows/command-dispatcher.yml transforme le commentaire en exécution de workflow.

Options, comme documenté dans CONTRIBUTING.md :

• groups=row-element-test,icon-element-test exécute les groupes nommés <test name="..."> depuis le XML de la suite.
• tests=RowColumnLayoutVisualTest exécute les classes de test nommées.
• maven_ref=branch-name utilise une branche dxpr_maven, pour revoir ensemble un changement du builder et sa mise à jour de test.

Le workflow téléverse target/reports/** et les captures comme artefact de build et poste le résultat en commentaire sur la pull request, listant les échecs ou les tests passés seulement en réessai. Chaque job de suite a un délai de 90 minutes.

Linters et analyse statique

Chaque linter est un service Docker Compose, donc aucune chaîne d’outils locale n’est requise au-delà de Docker.

Des variantes de correction auto existent pour phpcs, ESLint et Stylelint (drupal-lint-auto-fix, eslint-auto-fix, stylelint-auto-fix). Les mêmes vérifications existent sans Docker via npm run lint:scss, npm run lint:no-jquery, npm run lint:no-underscore et npm run lint:html-in-js.

npm install installe aussi un hook pre-commit Husky (.husky/pre-commit). Il exécute les services de correction auto et de lint correspondants sur les fichiers JavaScript, PHP et SCSS stagés et les sources Rust, et docs/video-tools/bin/lint-videos.mjs quand des fichiers sous docs/ sont stagés.

.github/workflows/review.yaml exécute les linters correspondant aux chemins changés sur chaque pull request. .github/workflows/main.yaml exécute drupal-lint, eslint, drupal-check-D11 et rust-lint sur chaque push sur 3.x. Les deux font échouer le build quand une vérification échoue et écrivent un résumé avec les fichiers fautifs.

Et ensuite ?

• Contribuer pour le processus de pull request et le flux maven_ref pour les mises à jour de tests.
• Commandes Drush pour les commandes exercées par la suite Bash.