Testes.

O DXPR Builder tem quatro tipos de verificações automatizadas: um teste Puppeteer do editor, testes Bash de ponta a ponta para os comandos Drush, uma suite Selenium de regressão visual no repositório separado dxpr_maven, e linters. Esta página enumera cada uma, como a correr localmente e como a CI a corre.

O que existe

O único teste PHPUnit no repositório é modules/dxpr_builder_media/tests/src/FunctionalJavascript/MediaEntityBrowserTest.php para o submódulo legado de multimédia. Nenhum fluxo de GitHub o corre; o pipeline GitLab de drupal.org (.gitlab-ci.yml) usa os modelos DrupalCI padrão, cuja tarefa PHPUnit não está desligada lá.

Teste de consola do editor

test/test-editor.js inicia um servidor estático na porta 3000 (test/start-standalone-server.js) e abre quatro páginas autónomas de test/standalone-editor/ em Chrome headless: test-bs5-anon.html, test-bs5-cms-block.html, test-bs5-editor.html e test-bs5-clean-html.html. Falha quando:

• uma página lança um erro JavaScript;
• o editor completo não está pronto em 2000 ms, ou restam controlos fora do ecrã adiados após o carregamento (a fasquia de desempenho);
• os controlos de elemento sobrepõem-se no modo de utilizador avançado (a referência é zero pares sobrepostos);
• o HTML guardado da página do editor completo é maior do que a referência de 32 094 carateres;
• uma verificação específica de página falha, por exemplo a análise de HTML Bootstrap limpo, o breadcrumb, os tipos de painel, o vídeo local, a definição Muted ou a pré-visualização de bloco CMS.

As páginas carregam os ficheiros compilados de dxpr_builder/, por isso compile primeiro.

1. Instale as dependências:

   npm install
   

2. Compile o pacote do editor. O script de CI corre estas tarefas por esta ordem (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. Corra o teste:

   npm run fe-test
   

   Use npm run fe-test:headed para ver o navegador, e npm run fe-test:dev para servir as páginas autónomas sem correr asserções.

Na CI, .github/workflows/fe-test.yaml corre o mesmo teste através de Docker:

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

Testes Drush de ponta a ponta

scripts/drush-e2e/run-e2e-tests.sh instala um site Drupal 11 novo com SQLite dentro de um contentor Composer, liga o módulo por symlink, ativa-o, cria um tipo de conteúdo Basic page com o formatador dxpr_builder_text, um modelo de página e um modelo de utilizador, e depois corre cada ficheiro scripts/drush-e2e/test-*.sh:

Corra todos:

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

Corra um ficheiro passando parte do nome; o script corresponde a scripts/drush-e2e/test-*<filter>*.sh:

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

Para adicionar um teste, crie scripts/drush-e2e/test-<name>.sh, chame section "<Title>", e use os auxiliares de scripts/drush-e2e/_helpers.sh: assert_success, assert_fail, assert_eq, assert_has, assert_not_empty, assert_runs e assert_dry_run. Cada auxiliar recebe uma descrição e uma cadeia de comando.

Na CI, esta suite é a tarefa "Run Drush E2E tests" em .github/workflows/review.yaml. Corre quando um pull request muda ficheiros .php, .module, .inc, .install, .yml, .md, composer.json ou composer.lock.

Suite Selenium de regressão visual

Os testes de navegador são suites Java TestNG no repositório dxpr_maven. Correm contra uma stack Docker definida em docker-compose.test.yml (hub Selenium, nós Chrome e um contentor Maven) num site instalado a partir deste repositório. Não os corre a partir de uma cópia local; desencadeia-os a partir de um comentário de pull request. .github/workflows/command-dispatcher.yml transforma o comentário numa execução de fluxo.

Opções, como documentado em CONTRIBUTING.md:

• groups=row-element-test,icon-element-test corre os grupos <test name="..."> indicados do XML da suite.
• tests=RowColumnLayoutVisualTest corre as classes de teste indicadas.
• maven_ref=branch-name usa um ramo dxpr_maven, que é como uma alteração do construtor e a atualização de teste são revistas juntas.

O fluxo carrega target/reports/** e as capturas de ecrã como artefacto de compilação e publica o resultado como comentário no pull request, enumerando falhas ou testes que só passaram à segunda. Cada tarefa de suite tem um tempo limite de 90 minutos.

Linters e análise estática

Cada linter é um serviço Docker Compose, por isso não é precisa toolchain local além de Docker.

Existem variantes de correção automática para phpcs, ESLint e Stylelint (drupal-lint-auto-fix, eslint-auto-fix, stylelint-auto-fix). As mesmas verificações existem sem Docker através de npm run lint:scss, npm run lint:no-jquery, npm run lint:no-underscore e npm run lint:html-in-js.

npm install também instala um hook pre-commit Husky (.husky/pre-commit). Corre a correção automática e os serviços de lint correspondentes nos ficheiros JavaScript, PHP e SCSS em stage e nas fontes Rust, e docs/video-tools/bin/lint-videos.mjs quando há ficheiros sob docs/ em stage.

.github/workflows/review.yaml corre os linters que correspondem aos caminhos alterados em cada pull request. .github/workflows/main.yaml corre drupal-lint, eslint, drupal-check-D11 e rust-lint em cada push para 3.x. Ambos falham a compilação quando uma verificação falha e escrevem um resumo com os ficheiros infratores.

O que se segue?

• Contribuir para o processo de pull request e o fluxo maven_ref para atualizações de teste.
• Comandos Drush para os comandos que a suite Bash exercita.