---
url: 'https://dxpr.com/pt-pt/hc/documentacao/aprender-dxpr-builder/desenvolvimento/testes'
title: 'Testes | DXPR'
author:
  name: Jurriaan
  url: 'https://dxpr.com/users/jurriaan'
date: '2026-10-24T11:48:09+00:00'
updated: '2026-10-24T17:19:22+00:00'
copyright: 'Copyright DXPR. All rights reserved.'
type: article
summary: |-
  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.
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: Testes
      description: |-
        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.
      image:
        '@type': ImageObject
        url: 'https://dxpr.com/themes/custom/dxpr_com/images/dxpr-share-card.jpg'
        width: '1200'
        height: '630'
      datePublished: '2026-10-24T11:48: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/pt-pt/hc/documentacao/aprender-dxpr-builder/desenvolvimento/testes'
      articleSection: Ferramentas
    -
      '@type': WebPage
      '@id': 'https://dxpr.com/pt-pt/hc/documentacao/aprender-dxpr-builder/desenvolvimento/testes'
      description: |-
        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.
      breadcrumb:
        '@type': BreadcrumbList
        itemListElement:
          -
            '@type': ListItem
            position: 1
            name: Início
            item: 'https://dxpr.com/pt-pt'
      publisher:
        '@type': Organization
        '@id': 'https://dxpr.com/#organization'
        name: DXPR
      inLanguage: pt-pt
---
[Centro de ajuda](/pt-pt/node/75)/[Documentação](/pt-pt/hc/documentacao) /[Aprender DXPR Builder](/pt-pt/hc/documentation/learn-dxpr-builder) /[Estender](/pt-pt/hc/documentation/learn-dxpr-builder/extend) /[Ferramentas](/pt-pt/hc/documentation/learn-dxpr-builder/extend/tooling) # Testes.

 Aprender DXPR BuilderEstenderFerramentas

   ## Neste guia

 Guias relacionados

- [Contribuir](/pt-pt/hc/documentacao/aprender-dxpr-builder/desenvolvimento/contribuir)
- [Comandos Drush](/pt-pt/hc/documentacao/aprender-dxpr-builder/desenvolvimento/comandos-drush)

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

| Check | Where it lives | Runs on |
|---|---|---|
| Teste de consola e esquema do editor | `test/test-editor.js` | Pull requests que tocam JavaScript, HTML ou `test/` (`.github/workflows/fe-test.yaml`) |
| Testes Drush de ponta a ponta | `scripts/drush-e2e/` | Pull requests que tocam PHP, YAML ou Markdown (`.github/workflows/review.yaml`) |
| Suite Selenium de regressão visual | `dxpr_maven`, o repositório | Comandos em comentários de PR (`.github/workflows/e2e-command.yaml`, `e2e-bs3-command.yml`, `e2eV2-command.yaml`) |
| Padrões de código PHP (phpcs) | `scripts/linters/run-drupal-lint.sh`, `phpcs.xml.dist` | Pull requests que tocam PHP, YAML ou Markdown; cada push para `3.x` |
| PHPStan | `scripts/linters/run-drupal-check.sh` | Pull requests que tocam PHP, YAML ou Markdown; cada push para `3.x` |
| ESLint, Stylelint, Rust Clippy | `scripts/linters/` | Pull requests, filtrados por caminhos alterados |
| Detetores de depreciação | `.github/workflows/deprecations.yml` | Pull requests que tocam `js/` ou `dxpr_builder/build/` |
| Verificações de docs (markdownlint, `check_docs.py`, Vale) | `.markdownlint-cli2.yaml`, `docs/lint/`, `.vale.ini` | Pull requests que tocam `docs/` (`review.yaml`) |

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:

    ```bash
    npm install

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

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

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

| File | Commands under test |
|---|---|
| `test-cleartext-key-update.sh` | A atualização 9026 limpa uma chave de produto em texto claro deixada no armazenamento do módulo Key, e mantém-na quando a Key escolhida desapareceu (`cleartext-key-update.php`) |
| `test-cms-cache-tags.sh` | Invalidação de cache das listagens de blocos e vistas (`cms-cache-tags.php`) |
| `test-elements.sh` | `drush dxb:element:list` |
| `test-migration-summary.sh` | Redação singular e plural do resumo da coluna de migração (`migration-summary.php`) |
| `test-migrations.sh` | `drush dxb:migrate` e regressões de migração de conteúdo (`migration-regressions.php`) |
| `test-page-controller.sh` | As construções do controlador de página para as rotas (`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` | O módulo Drag and Drop Page traz toda a configuração que enumera (`page-module.php`) |
| `test-profile-buttons.sh` | Botões do editor de texto de perfis do construtor (`profile-buttons.php`) |
| `test-profile-order.sh` | Que perfil se aplica por peso, e a ordem da lista de perfis (`profile-order.php`) |
| `test-settings-form.sh` | Guardar e validar a chave de produto em **General Settings**, e a sincronização de licença que desencadeia (`settings-form.php`) |
| `test-setup-ai.sh` | `drush dxb:setup-ai` |
| `test-templates.sh` | `drush dxb:template:list` |
| `test-user-licenses-page.sh` | O cartão de licença aparece uma vez em **User Licenses** e continua a aparecer em **People** (`user-licenses-page.php`) |
| `test-user-settings.sh` | As definições de editor próprias de cada editor (`user-settings.php`) |
| `test-user-templates.sh` | `drush dxb:user-template:list`, `drush dxb:user-template:create` |

Corra todos:

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

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

| Command | Suite | Workflow |
|---|---|---|
| `/e2e` | `chrome.editor.bs5.parallel.xml` mais a suite BS5 anónima | `e2e-command.yaml` |
| `/e2e-bs3` | `chrome.editor.bs3.parallel.xml` | `e2e-bs3-command.yml` |
| `/e2eV2` | Suites de editor e anónima BS5 na stack DXPR CMS | `e2eV2-command.yaml` |
| `/qa-demo-2x-dxpr_theme6x-tests` | Demo QA com DXPR Theme 6.x | `qa-demo-2x-dxpr_theme6x-tests-command.yaml` |

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.

| Service | Command | What it checks |
|---|---|---|
| `drupal-lint` | `docker compose run --rm drupal-lint` | phpcs com PHPCompatibility (PHP 8.3 e acima), `Drupal` e `DrupalPractice` aplicados |
| `drupal-check-D11` | `docker compose run --rm drupal-check-D11` | PHPStan nível 5 com `mglaman/phpstan-drupal` dentro de um novo `drupal/recommended-project` |
| `eslint` | `docker compose run --rm eslint` | ESLint em `js/` e `dxpr_builder/build/`, mais verificação ortográfica de `dxpr_builder/extracted_t_functions.js` |
| `stylelint` | `docker compose run --rm stylelint` | Stylelint em `dxpr_builder/sass/` e `sass/` |
| `rust-lint` | `docker compose run --rm rust-lint` | Clippy nas fontes Rust em `rust/` |
| `no-jquery`, `no-underscore`, `html-in-js` | `docker compose run --rm <service>` | Detetores de depreciação de `.github/workflows/deprecations.yml` |

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](/pt-pt/hc/documentation/learn-dxpr-builder/development/contributing) para o processo de pull request e o fluxo `maven_ref` para atualizações de teste.
- [Comandos Drush](/pt-pt/hc/documentacao/aprender-dxpr-builder/desenvolvimento/comandos-drush) para os comandos que a suite Bash exercita.