Test.

DXPR Builder ha quattro tipi di controlli automatici: un test Puppeteer dell’editor, test Bash end-to-end per i comandi Drush, una suite Selenium di regressione visiva nel repository separato dxpr_maven e linter. Questa pagina elenca ciascuno, come eseguirlo in locale e come CI lo esegue.

Cosa esiste

L’unico test PHPUnit nel repository è modules/dxpr_builder_media/tests/src/FunctionalJavascript/MediaEntityBrowserTest.php per il sottomodulo media legacy. Nessun workflow GitHub lo esegue; la pipeline GitLab di drupal.org (.gitlab-ci.yml) usa i template DrupalCI standard, il cui job PHPUnit non è disattivato lì.

Test console dell’editor

test/test-editor.js avvia un server statico sulla porta 3000 (test/start-standalone-server.js) e apre quattro pagine standalone da test/standalone-editor/ in Chrome headless: test-bs5-anon.html, test-bs5-cms-block.html, test-bs5-editor.html e test-bs5-clean-html.html. Fallisce quando:

• una pagina lancia un errore JavaScript;
• l’editor completo non è pronto entro 2000 ms, o non restano controlli fuori schermo differiti dopo il caricamento (il gate di performance);
• i controlli degli elementi si sovrappongono in modalità Power user (la baseline è zero coppie sovrapposte);
• l’HTML salvato della pagina dell’editor completo è più grande del riferimento di 32.094 caratteri;
• un controllo specifico di pagina fallisce, ad esempio il parsing di HTML Bootstrap pulito, il breadcrumb, i tipi Panel, l’impostazione Muted del video locale o l’anteprima del blocco CMS.

Le pagine caricano i file compilati da dxpr_builder/, quindi compila prima.

1. Installa le dipendenze:

   npm install
   

2. Compila il bundle dell’editor. Lo script CI esegue questi task in quest’ordine (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. Esegui il test:

   npm run fe-test
   

   Usa npm run fe-test:headed per guardare il browser, e npm run fe-test:dev per servire le pagine standalone senza eseguire asserzioni.

In CI, .github/workflows/fe-test.yaml esegue lo stesso test tramite Docker:

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

Test Drush end-to-end

scripts/drush-e2e/run-e2e-tests.sh installa un sito Drupal 11 nuovo con SQLite dentro un container Composer, vi collega il modulo con symlink, lo attiva, crea un tipo di contenuto Basic page con il formatter dxpr_builder_text, un modello di pagina e un modello utente, poi esegue ogni file scripts/drush-e2e/test-*.sh:

Eseguili tutti:

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

Esegui un file passando parte del suo nome; lo script confronta scripts/drush-e2e/test-*<filter>*.sh:

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

Per aggiungere un test, crea scripts/drush-e2e/test-<name>.sh, chiama section "<Title>", e usa gli helper da scripts/drush-e2e/_helpers.sh: assert_success, assert_fail, assert_eq, assert_has, assert_not_empty, assert_runs e assert_dry_run. Ogni helper prende una descrizione e una stringa di comando.

In CI questa suite è il job "Run Drush E2E tests" in .github/workflows/review.yaml. Gira quando una pull request modifica file .php, .module, .inc, .install, .yml, .md, composer.json o composer.lock.

Suite Selenium di regressione visiva

I test browser sono suite Java TestNG nel repository dxpr_maven. Girano contro uno stack Docker definito in docker-compose.test.yml (hub Selenium, nodi Chrome e container Maven) su un sito installato da questo repository. Non li esegui da un checkout locale; li avvii da un commento di pull request. .github/workflows/command-dispatcher.yml trasforma il commento in un’esecuzione di workflow.

Opzioni, come documentato in CONTRIBUTING.md:

• groups=row-element-test,icon-element-test esegue i gruppi <test name="..."> indicati dall’XML della suite.
• tests=RowColumnLayoutVisualTest esegue le classi di test indicate.
• maven_ref=branch-name usa un branch dxpr_maven, ed è così che una modifica del builder e il suo aggiornamento dei test sono revisionati insieme.

Il workflow carica target/reports/** e gli screenshot come artefatto di build e pubblica il risultato come commento sulla pull request, elencando fallimenti o test riusciti solo al retry. Ogni job di suite ha un timeout di 90 minuti.

Linter e analisi statica

Ogni linter è un servizio Docker Compose, quindi non serve toolchain locale oltre Docker.

Esistono varianti auto-fix per phpcs, ESLint e Stylelint (drupal-lint-auto-fix, eslint-auto-fix, stylelint-auto-fix). Gli stessi controlli sono disponibili senza Docker tramite npm run lint:scss, npm run lint:no-jquery, npm run lint:no-underscore e npm run lint:html-in-js.

npm install installa anche un hook pre-commit Husky (.husky/pre-commit). Esegue i servizi auto-fix e lint corrispondenti sui file JavaScript, PHP e SCSS nello stage e sui sorgenti Rust, e docs/video-tools/bin/lint-videos.mjs quando sono in stage file sotto docs/.

.github/workflows/review.yaml esegue i linter corrispondenti ai percorsi modificati su ogni pull request. .github/workflows/main.yaml esegue drupal-lint, eslint, drupal-check-D11 e rust-lint su ogni push a 3.x. Entrambi falliscono la build quando un controllo fallisce e scrivono un riepilogo con i file colpevoli.

Prossimi passi

• Come contribuire per il processo di pull request e il flusso maven_ref per gli aggiornamenti dei test.
• Comandi Drush per i comandi esercitati dalla suite Bash.