--- url: 'https://dxpr.com/fr/hc/documentation/apprendre-dxpr-builder/developpement/tests' title: 'Tests | DXPR' author: name: Jurriaan url: 'https://dxpr.com/users/jurriaan' date: '2026-10-24T11:01:10+00:00' updated: '2026-10-24T17:19:22+00:00' copyright: 'Copyright DXPR. All rights reserved.' type: article summary: '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.' tags: - Tooling image: 'https://dxpr.com/themes/custom/dxpr_com/images/dxpr-share-card.jpg' published: true og: site_name: DXPR updated_time: '2026-10-24T17:19:22+0000' 'image:alt': 'DXPR, powered by Drupal: AI-powered Drupal for marketers.' schema: '@context': 'https://schema.org' '@graph': - mainEntity: { } - '@type': TechArticle headline: Tests description: '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.' image: '@type': ImageObject url: 'https://dxpr.com/themes/custom/dxpr_com/images/dxpr-share-card.jpg' width: '1200' height: '630' datePublished: '2026-10-24T11:01:10+0000' dateModified: '2026-10-24T17:19:22+0000' author: '@type': Organization '@id': 'https://dxpr.com/#organization' name: DXPR url: 'https://dxpr.com/' logo: '@type': ImageObject url: 'https://dxpr.com/themes/custom/dxpr_com/dxpr-logo-dark.svg' width: '1348' height: '501' publisher: '@type': Organization '@id': 'https://dxpr.com/#organization' name: DXPR url: 'https://dxpr.com/' logo: '@type': ImageObject url: 'https://dxpr.com/themes/custom/dxpr_com/dxpr-logo-dark.svg' width: '1348' height: '501' mainEntityOfPage: 'https://dxpr.com/fr/hc/documentation/apprendre-dxpr-builder/developpement/tests' articleSection: Outils - '@type': WebPage '@id': 'https://dxpr.com/fr/hc/documentation/apprendre-dxpr-builder/developpement/tests' description: '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.' breadcrumb: '@type': BreadcrumbList itemListElement: - '@type': ListItem position: 1 name: Accueil item: 'https://dxpr.com/fr' publisher: '@type': Organization '@id': 'https://dxpr.com/#organization' name: DXPR inLanguage: fr --- [Centre d’aide](/fr/hc)/[Documentation](/fr/hc/documentation) /[Apprendre DXPR Builder](/fr/hc/documentation/learn-dxpr-builder) /[Étendre](/fr/hc/documentation/learn-dxpr-builder/extend) /[Outils](/fr/hc/documentation/learn-dxpr-builder/extend/tooling) # Tests. Apprendre DXPR BuilderÉtendreOutils ## Dans ce guide Guides associés - [Contribuer à DXPR Builder](/fr/hc/documentation/apprendre-dxpr-builder/developpement/contribuer) - [Commandes Drush](/fr/hc/documentation/apprendre-dxpr-builder/developpement/commandes-drush) 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 | Vérification | Où elle vit | S’exécute sur | |---|---|---| | Test console et mise en page de l’éditeur | `test/test-editor.js` | Pull requests qui touchent JavaScript, HTML ou `test/` (`.github/workflows/fe-test.yaml`) | | Tests Drush de bout en bout | `scripts/drush-e2e/` | Pull requests qui touchent PHP, YAML ou Markdown (`.github/workflows/review.yaml`) | | Suite Selenium de régression visuelle | `dxpr_maven` (dépôt séparé) | Commandes en commentaire de PR (`.github/workflows/e2e-command.yaml`, `e2e-bs3-command.yml`, `e2eV2-command.yaml`) | | Standards de code PHP (phpcs) | `scripts/linters/run-drupal-lint.sh`, `phpcs.xml.dist` | Pull requests qui touchent PHP, YAML ou Markdown ; chaque push sur `3.x` | | PHPStan | `scripts/linters/run-drupal-check.sh` | Pull requests qui touchent PHP, YAML ou Markdown ; chaque push sur `3.x` | | ESLint, Stylelint, Rust Clippy | `scripts/linters/` | Pull requests, filtrées par chemins changés | | Détecteurs d’obsolescence | `.github/workflows/deprecations.yml` | Pull requests qui touchent `js/` ou `dxpr_builder/build/` | | Vérifications de docs (markdownlint, `check_docs.py`, Vale) | `.markdownlint-cli2.yaml`, `docs/lint/`, `.vale.ini` | Pull requests qui touchent `docs/` (`review.yaml`) | 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 : ```bash 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`) : ```bash npx grunt concat npx grunt exec:gen npx grunt babel npx grunt terser npx grunt sass npx grunt postcss ``` 3. Exécutez le test : ```bash 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 : ```bash 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` : | Fichier | Commandes testées | |---|---| | `test-cleartext-key-update.sh` | La mise à jour 9026 efface une clé de produit en clair restée sous stockage module Key, et la garde quand la Key choisie a disparu (`cleartext-key-update.php`) | | `test-cms-cache-tags.sh` | Invalidation de cache des listes de blocs et de vues (`cms-cache-tags.php`) | | `test-elements.sh` | `drush dxb:element:list` | | `test-migration-summary.sh` | Formulation singulier et pluriel du résumé de la colonne de migration (`migration-summary.php`) | | `test-migrations.sh` | `drush dxb:migrate` et régressions de migration de contenu (`migration-regressions.php`) | | `test-page-controller.sh` | Les builds du contrôleur de page pour ses routes (`page-controller.php`) | | `test-page-create.sh` | `drush dxb:page:create` | | `test-page-get-update.sh` | `drush dxb:page:get`, `drush dxb:page:update` | | `test-page-module.sh` | Le module Drag and Drop Page livre chaque configuration listée (`page-module.php`) | | `test-profile-buttons.sh` | Boutons d’éditeur de texte des profils du builder (`profile-buttons.php`) | | `test-profile-order.sh` | Quel profil s’applique par poids, et l’ordre de la liste des profils (`profile-order.php`) | | `test-settings-form.sh` | Enregistrement et validation de la clé de produit sur **General Settings**, et la synchro de licence déclenchée (`settings-form.php`) | | `test-setup-ai.sh` | `drush dxb:setup-ai` | | `test-templates.sh` | `drush dxb:template:list` | | `test-user-licenses-page.sh` | La carte de licence s’affiche une fois sur **User Licenses** et toujours sur **People** (`user-licenses-page.php`) | | `test-user-settings.sh` | Les réglages d’éditeur propres à chaque contributeur (`user-settings.php`) | | `test-user-templates.sh` | `drush dxb:user-template:list`, `drush dxb:user-template:create` | Exécutez-les tous : ```bash 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-**.sh` : ```bash docker compose --profile drush-e2e run --rm e2e-test page-create ``` Pour ajouter un test, créez `scripts/drush-e2e/test-.sh`, appelez `section ""`, 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. | Commande | Suite | Workflow | |---|---|---| | `/e2e` | `chrome.editor.bs5.parallel.xml` plus la suite BS5 anonyme | `e2e-command.yaml` | | `/e2e-bs3` | `chrome.editor.bs3.parallel.xml` | `e2e-bs3-command.yml` | | `/e2eV2` | Suites éditeur et anonymes BS5 sur la stack DXPR CMS | `e2eV2-command.yaml` | | `/qa-demo-2x-dxpr_theme6x-tests` | Démo QA avec DXPR Theme 6.x | `qa-demo-2x-dxpr_theme6x-tests-command.yaml` | 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. | Service | Commande | Ce qu’il vérifie | |---|---|---| | `drupal-lint` | `docker compose run --rm drupal-lint` | phpcs avec PHPCompatibility (PHP 8.3 et plus), `Drupal` et `DrupalPractice` standards | | `drupal-check-D11` | `docker compose run --rm drupal-check-D11` | PHPStan niveau 5 avec `mglaman/phpstan-drupal` dans `drupal/recommended-project` | | `eslint` | `docker compose run --rm eslint` | ESLint sur `js/` et `dxpr_builder/build/`, plus une vérification orthographique de `dxpr_builder/extracted_t_functions.js` | | `stylelint` | `docker compose run --rm stylelint` | Stylelint sur `dxpr_builder/sass/` et `sass/` | | `rust-lint` | `docker compose run --rm rust-lint` | Clippy sur les sources Rust dans `rust/` | | `no-jquery`, `no-underscore`, `html-in-js` | `docker compose run --rm <service>` | Détecteurs d’obsolescence depuis `.github/workflows/deprecations.yml` | 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](/fr/hc/documentation/learn-dxpr-builder/development/contributing) pour le processus de pull request et le flux `maven_ref` pour les mises à jour de tests. - [Commandes Drush](/fr/hc/documentation/apprendre-dxpr-builder/developpement/commandes-drush) pour les commandes exercées par la suite Bash.