Testes

O formato da suíte de testes espelha o produto: verificações pre-flight numeradas, depois arquivos por funcionalidade, além de suítes de regressão ligadas a números de issue específicos, testes adversariais de "exploit" para vulnerabilidades passadas e a suíte separada do MCP. Esta página mapeia a cobertura.

Os arquivos pre-flight

• 00-compile.t: a aplicação inteira compila (é ignorado de forma limpa se Mojolicious/DBI não estiverem instalados, pois é uma verificação de fumaça, não um instalador de dependências).
• 01-schema.t: o próprio schema é o que as migrations depois reproduzem; este teste valida o arquivo de schema.
• 02-media-sniff.t: comportamento de sniffing no upload de mídia.
• 03-util.t, 04-webhook.t: suítes unitárias da camada de utilitários e do despacho de webhooks.

Suítes por funcionalidade

Cada entidade gerenciada pela API ganha uma suíte própria, geralmente uma por área: pages, posts, blocks (incluindo helpers por tipo e a paleta de tipos de bloco), snippets, categories, media, documents, nav, redirects, themes, users, audit, drafts_restore, library, health, i18n, settings. Formulários e submissões também são uma área própria (forms.t, submissions.t, submission_values.t), incluindo os testes de restrições de upload de arquivos e de cota.

Regressões de segurança e adversariais

Uma família dedicada exploit_… de testes recria como testes os exploits reportados historicamente, cada um com um comentário descrevendo a vulnerabilidade corrigida:

• Chaves de API somente leitura contornando os portões de escrita (#4827): o portão de sessão aceitava chaves de API com escopo de leitura em rotas de mutação; o teste força o portão a exigir escopo de escrita para POST/PUT/PATCH/DELETE.
• Escalada de privilégio na navegação via API: alterar entradas de navegação (e o intake do log de 404 do admin) com uma chave de escopo insuficiente é rejeitado.
• Contagem dupla no rate limit da API: o contador de rate limit por chave deve incrementar uma vez por requisição HTTP (uma regressão anterior o contava por camada de autenticação).
• Path traversal em documentos: nomes de arquivo forjados tentando escapar do diretório de documentos.
• Mass-assignment em formulários: enviar por POST valores para campos que o formulário nunca declarou é rejeitado.
• Injeção de dot-placeholder em arquivos de tema: o tratamento de caminhos do editor de arquivos de tema bloqueia caminhos forjados.
• Uma varredura de regressão de segurança (exploit_security_regression.t): uma suíte adversarial ampla.

A convenção de nomes (exploit_issue_tag.t) torna toda vulnerabilidade "testável por regressão": cada uma é rotulada com um número de issue específico, para que mudanças futuras saibam qual correção não podem quebrar.

Uma suíte inteira para os comportamentos do subsistema de backup

Vários arquivos separados cobrem a maquinaria de backup e restauração (backup_*.t): criação de snapshots, retenção, prévias dry-run de restauração e confirmação, validação de manifest, retenção, restaurações via API.

Suítes de comportamento de build

• Teste mínimo: os build_helpers executam ondas de renderização por idioma com a verificação de microscopia Hunni (os builds da review-api).
• build_speed_4636/4637/4638: a série de testes de desempenho de build paralelo; uma suíte de "timings" por build valida os tempos por fase contra testes de fixture; builds incrementais são verificados em um teste de modo misto.
• As suítes de build medem em um corpus pequeno verificando caminhos de código (fingerprint, minificação, varreduras de links, schema) e confirmam condições de data race/tempo de relógio (via exemplos de build_speed_4637, as ideias de regressão de múltiplas velocidades).

Comportamentos de air-gap e de plataforma

• Comportamentos de e-mail com air-gap desativado (admin_email_airgap.t), caminhos de falha de SMTP (admin_email_smtp.t, form_email_smtp_fail.t) e verificações de CRLF do SMTP implementado à mão e forçado (form_email_crlf.t).
• Portão Turnstile: por trás das configurações turnstile_*, verifica painéis como uma suíte separada (turnstile_gate.t).
• Portas voltadas para cima do roteamento de URLs, escape de XML (segurança de sitemap/feed) e verificação de statements nos shadow guards de rotas.

A miscelânea de suítes que vale conhecer

• A suíte de migrations verifica a unicidade de cada arquivo de migration quando reexecutado em um banco temporário (idempotência/reexecução segura) e cruza migration com schema, para que schema.sql e as migrations não possam divergir (migrations_lint.t, migrations_has_table.t, migrations_helpers.t).
• Os testes de instalação (installer-install.t, installer-bundle.t) cobrem o caminho de instalação por bundle offline.
• zz_phase80_verify.t roda por último (último em ordem alfabética) como uma camada de verificação que cruza várias áreas.

Nesta seção

• Executando a Suíte de Testes
• Referência do Test Helper