Testen.

DXPR Builder hat vier Arten automatisierter Prüfungen: einen Puppeteer-Test des Editors, Bash-End-to-End-Tests für die Drush-Befehle, eine Selenium-Suite für visuelle Regression im separaten dxpr_maven-Repository und Linter. Diese Seite listet jede, wie Sie sie lokal ausführen und wie CI sie ausführt.

Was existiert

Der einzige PHPUnit-Test im Repository ist modules/dxpr_builder_media/tests/src/FunctionalJavascript/MediaEntityBrowserTest.php für das alte Medien-Submodul. Kein GitHub-Workflow führt ihn aus; die drupal.org-GitLab-Pipeline (.gitlab-ci.yml) nutzt die Standard- DrupalCI-Vorlagen, deren PHPUnit-Job dort nicht abgeschaltet ist.

Editor-Konsolentest

test/test-editor.js startet einen statischen Server auf Port 3000 (test/start-standalone-server.js) und öffnet vier Standalone-Seiten aus test/standalone-editor/ in headless Chrome: test-bs5-anon.html, test-bs5-cms-block.html, test-bs5-editor.html und test-bs5-clean-html.html. Er scheitert, wenn:

• eine Seite einen JavaScript-Fehler wirft;
• der volle Editor nicht in 2000 ms bereit ist, oder nach dem Laden noch Steuerelemente außerhalb des Bildschirms verzögert bleiben (das Performance-Gate);
• Elementsteuerelemente im Power-User-Modus überlappen (die Baseline ist null überlappende Paare);
• das gespeicherte HTML der vollen Editorseite größer ist als die Referenz von 32.094 Zeichen;
• eine seitenspezifische Prüfung scheitert, zum Beispiel das Parsen von sauberem Bootstrap-HTML, die Breadcrumb, die Paneltypen, die Muted-Einstellung für lokale Videos oder die CMS-Block-Vorschau.

Die Seiten laden die gebauten Dateien aus dxpr_builder/, bauen Sie daher zuerst.

1. Abhängigkeiten installieren:

   npm install
   

2. Editor-Bundle bauen. Das CI-Skript führt diese Tasks in dieser Reihenfolge aus (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. Test ausführen:

   npm run fe-test
   

   Nutzen Sie npm run fe-test:headed, um den Browser zu beobachten, und npm run fe-test:dev, um die Standalone-Seiten ohne Assertions zu servieren.

In CI führt .github/workflows/fe-test.yaml denselben Test über Docker aus:

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

Drush-End-to-End-Tests

scripts/drush-e2e/run-e2e-tests.sh installiert eine frische Drupal-11-Website mit SQLite in einem Composer-Container, verlinkt das Modul hinein, aktiviert es, erzeugt einen Basic-Page-Inhaltstyp mit dem Formatierer dxpr_builder_text, eine Seitenvorlage und eine Benutzervorlage, dann führt es jede Datei scripts/drush-e2e/test-*.sh aus:

Alle ausführen:

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

Eine Datei ausführen, indem Sie einen Teil ihres Namens übergeben; das Skript matcht scripts/drush-e2e/test-*<filter>*.sh:

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

Um einen Test hinzuzufügen, erstellen Sie scripts/drush-e2e/test-<name>.sh, rufen section "<Title>" auf und nutzen die Helfer aus scripts/drush-e2e/_helpers.sh: assert_success, assert_fail, assert_eq, assert_has, assert_not_empty, assert_runs und assert_dry_run. Jeder Helfer nimmt eine Beschreibung und eine Befehlszeichenkette.

In CI ist diese Suite der Job „Run Drush E2E tests“ in .github/workflows/review.yaml. Er läuft, wenn ein Pull-Request .php-, .module-, .inc-, .install-, .yml-, .md-, composer.json- oder composer.lock-Dateien ändert.

Selenium-Suite für visuelle Regression

Die Browser-Tests sind Java-TestNG-Suiten im dxpr_maven-Repository. Sie laufen gegen einen Docker-Stack, definiert in docker-compose.test.yml (Selenium-Hub, Chrome-Nodes und ein Maven-Container), auf einer aus diesem Repository installierten Website. Sie führen sie nicht aus einem lokalen Checkout aus; Sie lösen sie aus einem Pull-Request-Kommentar aus. .github/workflows/command-dispatcher.yml macht aus dem Kommentar einen Workflow-Lauf.

Optionen, wie in CONTRIBUTING.md dokumentiert:

• groups=row-element-test,icon-element-test führt die benannten <test name="...">-Gruppen aus der Suite-XML aus.
• tests=RowColumnLayoutVisualTest führt die benannten Testklassen aus.
• maven_ref=branch-name nutzt einen dxpr_maven-Branch; so werden eine Builder-Änderung und ihre Testaktualisierung gemeinsam reviewt.

Der Workflow lädt target/reports/** und die Screenshots als Build-Artefakt hoch und postet das Ergebnis als Kommentar auf den Pull-Request, mit scheiternden oder nur im Wiederholungslauf bestandenen Tests. Jeder Suite-Job hat einen Timeout von 90 Minuten.

Linter und statische Analyse

Jeder Linter ist ein Docker-Compose-Dienst, daher braucht es außer Docker keine lokale Toolchain.

Auto-Fix-Varianten existieren für phpcs, ESLint und Stylelint (drupal-lint-auto-fix, eslint-auto-fix, stylelint-auto-fix). Dieselben Prüfungen gibt es ohne Docker über npm run lint:scss, npm run lint:no-jquery, npm run lint:no-underscore und npm run lint:html-in-js.

npm install installiert außerdem einen Husky-Pre-Commit-Hook (.husky/pre-commit). Er führt die passenden Auto-Fix- und Lint-Dienste auf den gestagten JavaScript-, PHP- und SCSS-Dateien und den Rust-Quellen aus, und docs/video-tools/bin/lint-videos.mjs, wenn Dateien unter docs/ gestagt sind.

.github/workflows/review.yaml führt die Linter, die zu den geänderten Pfaden passen, auf jedem Pull-Request aus. .github/workflows/main.yaml führt drupal-lint, eslint, drupal-check-D11 und rust-lint auf jedem Push auf 3.x aus. Beide lassen den Build scheitern, wenn eine Prüfung scheitert, und schreiben eine Übersicht mit den beanstandeten Dateien.

Wie geht es weiter?

• Mitwirken für den Pull-Request-Prozess und den maven_ref-Workflow für Testaktualisierungen.
• Drush-Befehle für die Befehle, die die Bash-Suite prüft.