---
url: 'https://dxpr.com/de/hc/dokumentation/dxpr-builder-lernen/entwicklung/testen'
title: 'Testen | DXPR'
author:
  name: Jurriaan
  url: 'https://dxpr.com/users/jurriaan'
date: '2026-10-24T04:05:09+00:00'
updated: '2026-10-24T17:19:22+00:00'
copyright: 'Copyright DXPR. All rights reserved.'
type: article
summary: |-
  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.
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: Testen
      description: |-
        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.
      image:
        '@type': ImageObject
        url: 'https://dxpr.com/themes/custom/dxpr_com/images/dxpr-share-card.jpg'
        width: '1200'
        height: '630'
      datePublished: '2026-10-24T04:05:09+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/de/hc/dokumentation/dxpr-builder-lernen/entwicklung/testen'
      articleSection: Werkzeuge
    -
      '@type': WebPage
      '@id': 'https://dxpr.com/de/hc/dokumentation/dxpr-builder-lernen/entwicklung/testen'
      description: |-
        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.
      breadcrumb:
        '@type': BreadcrumbList
        itemListElement:
          -
            '@type': ListItem
            position: 1
            name: Startseite
            item: 'https://dxpr.com/de'
      publisher:
        '@type': Organization
        '@id': 'https://dxpr.com/#organization'
        name: DXPR
      inLanguage: de
---
[Hilfe-Center](/de/hc)/[Dokumentation](/de/hc/dokumentation) /[DXPR Builder lernen](/de/hc/documentation/learn-dxpr-builder) /[Erweitern](/de/hc/documentation/learn-dxpr-builder/extend) /[Werkzeuge](/de/hc/documentation/learn-dxpr-builder/extend/tooling) # Testen.

 DXPR Builder lernenErweiternWerkzeuge

   ## In diesem Leitfaden

 Verwandte Leitfäden

- [Mitwirken](/de/hc/dokumentation/dxpr-builder-lernen/entwicklung/mitwirken)
- [Drush-Befehle](/de/hc/dokumentation/dxpr-builder-lernen/entwicklung/drush-befehle)

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

| Prüfung | Wo sie liegt | Läuft auf |
|---|---|---|
| Editor-Konsolen- und Layouttest | `test/test-editor.js` | Pull-Requests, die JavaScript, HTML oder `test/` berühren (`.github/workflows/fe-test.yaml`) |
| Drush-End-to-End-Tests | `scripts/drush-e2e/` | Pull-Requests, die PHP, YAML oder Markdown berühren (`.github/workflows/review.yaml`) |
| Selenium-Suite für visuelle Regression | `dxpr_maven`-Repository | PR-Kommentar-Befehle (`.github/workflows/e2e-command.yaml`, `e2e-bs3-command.yml`, `e2eV2-command.yaml`) |
| PHP-Coding-Standards (phpcs) | `scripts/linters/run-drupal-lint.sh`, `phpcs.xml.dist` | Pull-Requests, die PHP, YAML oder Markdown berühren; jeder Push auf `3.x` |
| PHPStan | `scripts/linters/run-drupal-check.sh` | Pull-Requests, die PHP, YAML oder Markdown berühren; jeder Push auf `3.x` |
| ESLint, Stylelint, Rust Clippy | `scripts/linters/` | Pull-Requests, gefiltert nach geänderten Pfaden |
| Deprecation-Detektoren | `.github/workflows/deprecations.yml` | Pull-Requests mit Änderungen an `js/` oder `dxpr_builder/build/` |
| Doku-Prüfungen (markdownlint, `check_docs.py`, Vale) | `.markdownlint-cli2.yaml`, `docs/lint/`, `.vale.ini` | Pull-Requests, die `docs/` berühren (`review.yaml`) |

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:

    ```bash
    npm install

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

    ```bash
    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:

```bash
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:

| Datei | Geprüfte Befehle |
|---|---|
| `test-cleartext-key-update.sh` | Update 9026 löscht einen Klartext-Produktschlüssel unter Key-Modul-Speicherung und behält ihn, wenn der gewählte Key weg ist (`cleartext-key-update.php`) |
| `test-cms-cache-tags.sh` | Cache-Invalidierung von Block- und Ansichtslisten (`cms-cache-tags.php`) |
| `test-elements.sh` | `drush dxb:element:list` |
| `test-migration-summary.sh` | Singular- und Pluralformulierung der Migrationsspalten-Übersicht (`migration-summary.php`) |
| `test-migrations.sh` | `drush dxb:migrate` und Inhaltsmigrations-Regressionen (`migration-regressions.php`) |
| `test-page-controller.sh` | Die Seiten-Controller-Builds für ihre Routen (`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` | Das Drag-and-drop-Page-Modul bringt jede Konfiguration mit, die es listet (`page-module.php`) |
| `test-profile-buttons.sh` | Texteditor-Schaltflächen von Builder-Profilen (`profile-buttons.php`) |
| `test-profile-order.sh` | Welches Profil per Weight greift, und die Reihenfolge der Profilliste (`profile-order.php`) |
| `test-settings-form.sh` | Speichern und Validieren des Produktschlüssels auf **General Settings** und der ausgelöste Lizenz-Sync (`settings-form.php`) |
| `test-setup-ai.sh` | `drush dxb:setup-ai` |
| `test-templates.sh` | `drush dxb:template:list` |
| `test-user-licenses-page.sh` | Die Lizenzkarte erscheint einmal auf **User Licenses** und weiterhin auf **People** (`user-licenses-page.php`) |
| `test-user-settings.sh` | Die eigenen Editor-Einstellungen jeder bearbeitenden Person (`user-settings.php`) |
| `test-user-templates.sh` | `drush dxb:user-template:list`, `drush dxb:user-template:create` |

Alle ausführen:

```bash
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`:

```bash
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.

| Befehl | Suite | Workflow |
|---|---|---|
| `/e2e` | `chrome.editor.bs5.parallel.xml` plus die anonyme BS5-Suite | `e2e-command.yaml` |
| `/e2e-bs3` | `chrome.editor.bs3.parallel.xml` | `e2e-bs3-command.yml` |
| `/e2eV2` | BS5-Editor- und Anonymous-Suiten auf dem DXPR-CMS-Stack | `e2eV2-command.yaml` |
| `/qa-demo-2x-dxpr_theme6x-tests` | QA-Demo mit DXPR Theme 6.x | `qa-demo-2x-dxpr_theme6x-tests-command.yaml` |

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.

| Dienst | Befehl | Was er prüft |
|---|---|---|
| `drupal-lint` | `docker compose run --rm drupal-lint` | phpcs mit PHPCompatibility (PHP 8.3 und höher), `Drupal`- und `DrupalPractice`-Standards |
| `drupal-check-D11` | `docker compose run --rm drupal-check-D11` | PHPStan Stufe 5 mit `mglaman/phpstan-drupal` in frischem `drupal/recommended-project` |
| `eslint` | `docker compose run --rm eslint` | ESLint auf `js/` und `dxpr_builder/build/`, plus Rechtschreibprüfung von `dxpr_builder/extracted_t_functions.js` |
| `stylelint` | `docker compose run --rm stylelint` | Stylelint auf `dxpr_builder/sass/` und `sass/` |
| `rust-lint` | `docker compose run --rm rust-lint` | Clippy auf den Rust-Quellen in `rust/` |
| `no-jquery`, `no-underscore`, `html-in-js` | `docker compose run --rm <service>` | Deprecation-Detektoren aus `.github/workflows/deprecations.yml` |

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](/de/hc/documentation/learn-dxpr-builder/development/contributing) für den Pull-Request-Prozess und den `maven_ref`-Workflow für Testaktualisierungen.
- [Drush-Befehle](/de/hc/dokumentation/dxpr-builder-lernen/entwicklung/drush-befehle) für die Befehle, die die Bash-Suite prüft.