Testowanie.

Kreator DXPR ma cztery rodzaje automatycznych kontroli: test edytora w Puppeteer, testy end-to-end w Bashu dla poleceń Drush, pakiet Selenium regresji wizualnej w osobnym repozytorium dxpr_maven i lintery. Ta strona wymienia każde z nich, jak je uruchomić lokalnie i jak uruchamia je CI.

Co istnieje

Jedyny test PHPUnit w repozytorium to modules/dxpr_builder_media/tests/src/FunctionalJavascript/MediaEntityBrowserTest.php dla starszego submodułu mediów. Żaden przebieg GitHub go nie uruchamia; potok GitLab drupal.org (.gitlab-ci.yml) używa standardowych szablonów DrupalCI, których zadanie PHPUnit nie jest tam wyłączone.

Test konsoli edytora

test/test-editor.js startuje serwer statyczny na porcie 3000 (test/start-standalone-server.js) i otwiera cztery samodzielne strony z test/standalone-editor/ w headless Chrome: test-bs5-anon.html, test-bs5-cms-block.html, test-bs5-editor.html i test-bs5-clean-html.html. Nie udaje się, gdy:

• strona rzuca błąd JavaScript;
• pełny edytor nie jest gotowy w 2000 ms albo po wczytaniu nie zostały odroczone żadne kontrolki poza ekranem (bramka wydajności);
• kontrolki elementów nakładają się w trybie zaawansowanego użytkownika (poziom bazowy to zero nakładających się par);
• zapisany HTML strony pełnego edytora jest większy niż wzorzec 32 094 znaków;
• kontrola specyficzna dla strony się nie udaje, na przykład parsowanie czystego HTML Bootstrapa, okruszek, typy paneli, lokalne ustawienie wideo Muted albo podgląd bloku CMS.

Strony wczytują zbudowane pliki z dxpr_builder/, więc najpierw zbuduj.

1. Zainstaluj zależności:

   npm install
   

2. Zbuduj pakiet edytora. Skrypt CI uruchamia te zadania w tej kolejności (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. Uruchom test:

   npm run fe-test
   

   Użyj npm run fe-test:headed, aby obserwować przeglądarkę, i npm run fe-test:dev, aby serwować samodzielne strony bez uruchamiania asercji.

W CI .github/workflows/fe-test.yaml uruchamia ten test przez Dockera:

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

Testy end-to-end Drush

scripts/drush-e2e/run-e2e-tests.sh instaluje świeżą witrynę Drupal 11 z SQLite wewnątrz kontenera Composer, dowiązuje do niej moduł, włącza go, tworzy typ treści Basic page z formaterem dxpr_builder_text, szablon strony i szablon użytkownika, potem uruchamia każdy plik scripts/drush-e2e/test-*.sh:

Uruchom wszystkie:

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

Uruchom jeden plik, podając część jego nazwy; skrypt dopasowuje scripts/drush-e2e/test-*<filter>*.sh:

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

Aby dodać test, utwórz scripts/drush-e2e/test-<name>.sh, wywołaj section "<Title>" i użyj helperów z scripts/drush-e2e/_helpers.sh: assert_success, assert_fail, assert_eq, assert_has, assert_not_empty, assert_runs i assert_dry_run. Każdy helper przyjmuje opis i ciąg polecenia.

W CI ten pakiet to zadanie „Run Drush E2E tests” w .github/workflows/review.yaml. Uruchamia się, gdy pull request zmienia pliki .php, .module, .inc, .install, .yml, .md, composer.json albo composer.lock.

Pakiet Selenium regresji wizualnej

Testy przeglądarkowe to pakiety Java TestNG w repozytorium dxpr_maven. Działają na stosie Docker zdefiniowanym w docker-compose.test.yml (hub Selenium, węzły Chrome i kontener Maven) na witrynie zainstalowanej z tego repozytorium. Nie uruchamiasz ich z lokalnej kopii; wyzwalasz je z komentarza pull requesta. .github/workflows/command-dispatcher.yml zamienia komentarz w uruchomienie przebiegu.

Opcje, jak udokumentowano w CONTRIBUTING.md:

• groups=row-element-test,icon-element-test uruchamia nazwane grupy <test name="..."> z XML pakietu.
• tests=RowColumnLayoutVisualTest uruchamia nazwane klasy testów.
• maven_ref=branch-name używa gałęzi dxpr_maven, dzięki czemu zmiana kreatora i jej aktualizacja testu recenzowane są razem.

Przebieg przesyła target/reports/** i zrzuty ekranu jako artefakt kompilacji i publikuje wynik jako komentarz w pull requeście, wymieniając nieudane albo testy, które przeszły dopiero po ponowieniu. Każde zadanie pakietu ma 90-minutowy limit czasu.

Lintery i analiza statyczna

Każdy linter jest usługą Docker Compose, więc poza Dockerem nie jest potrzebny żaden lokalny łańcuch narzędzi.

Warianty z automatyczną naprawą istnieją dla phpcs, ESLint i Stylelint (drupal-lint-auto-fix, eslint-auto-fix, stylelint-auto-fix). Te same kontrole są dostępne bez Dockera przez npm run lint:scss, npm run lint:no-jquery, npm run lint:no-underscore i npm run lint:html-in-js.

npm install instaluje też hook pre-commit Husky (.husky/pre-commit). Uruchamia pasujące usługi auto-fix i lint na staged plikach JavaScript, PHP i SCSS oraz źródłach Rust, a docs/video-tools/bin/lint-videos.mjs, gdy pliki w docs/ są staged.

.github/workflows/review.yaml uruchamia lintery pasujące do zmienionych ścieżek przy każdym pull requeście. .github/workflows/main.yaml uruchamia drupal-lint, eslint, drupal-check-D11 i rust-lint przy każdym wypchnięciu do 3.x. Oba nie udają kompilacji, gdy kontrola się nie powiedzie, i zapisują podsumowanie z naruszającymi plikami.

Co dalej?

• Współtworzenie dla procesu pull requestów i przebiegu maven_ref dla aktualizacji testów.
• Polecenia Drush dla poleceń ćwiczonych przez pakiet Bash.