Tests

La forme de la suite de tests reflète celle du produit : des vérifications préalables numérotées, puis des fichiers par fonctionnalité, plus des suites de régression liées à des numéros de ticket précis, des tests adverses « exploit » pour des vulnérabilités passées, et la suite MCP séparée. Cette page cartographie la couverture.

Les fichiers de vérification préalable

• 00-compile.t : toute l'application compile (saute proprement si Mojolicious/DBI ne sont pas installés, puisqu'il s'agit d'un smoke check et non d'un installateur de dépendances).
• 01-schema.t : le schéma lui-même est ce que les migrations reproduisent ensuite ; ce test valide le fichier de schéma.
• 02-media-sniff.t : comportement de détection du type des médias téléversés.
• 03-util.t, 04-webhook.t : suites unitaires de la couche utilitaire et de l'envoi des webhooks.

Suites par fonctionnalité

Chaque entité gérée par l'API a sa propre suite, généralement une par domaine : pages, posts, blocks (y compris les helpers par type et la palette des types de block), snippets, catégories, media, documents, nav, redirects, thèmes, utilisateurs, audit, drafts_restore, library, health, i18n, réglages. Les formulaires et les soumissions sont aussi un domaine à part (forms.t, submissions.t, submission_values.t), y compris les restrictions sur les téléversements de fichiers et les tests de quota.

Régressions de sécurité et adverses

Une famille dédiée de tests exploit_… recrée sous forme de tests des exploits signalés historiquement, chacun avec un commentaire décrivant la vulnérabilité corrigée :

• Clés API en lecture seule contournant les garde-fous d'écriture (#4827) : le garde de session acceptait des clés API à portée lecture sur des routes de mutation ; le test force le garde à exiger la portée écriture pour POST/PUT/PATCH/DELETE.
• Escalade de privilèges via l'API nav : la mutation d'entrées de navigation (et de l'entrée du journal 404 de l'admin) avec une clé de portée trop limitée est rejetée.
• Double comptage du rate-limit de l'API : le compteur de limite par clé doit s'incrémenter une seule fois par requête HTTP (une régression le comptait auparavant par couche d'authentification).
• Traversée de chemin dans les documents : noms de fichiers forgés tentant de sortir du répertoire des documents.
• Mass-assignment des formulaires : l'envoi par POST de valeurs pour des champs que le formulaire n'a jamais déclarés est rejeté.
• Injection de dot-placeholder dans les fichiers de thème : la gestion des chemins de l'éditeur de fichiers de thème bloque les chemins forgés.
• Un balayage de régression de sécurité (exploit_security_regression.t), une large suite adverse.

La convention de nommage (exploit_issue_tag.t) rend chaque vulnérabilité « testable en régression » : chacune est étiquetée avec un numéro de ticket précis afin que les changements futurs connaissent le correctif qu'ils ne doivent pas casser.

Une suite entière pour les comportements du sous-système de backup

Plusieurs fichiers distincts couvrent la mécanique de backup et de restore (backup_*.t) : création de snapshots, rétention, aperçus dry-run du restore et confirmation, validation du manifest, rétention, restores par API.

Suites de comportement du build

• Test minimal : les build_helpers exécutent des vagues de rendu par langue avec la vérification de microscopie Hunni (les builds de review-api).
• build_speed_4636/4637/4638 : la série de tests de performance du build parallèle ; une suite de « timings » par build valide les durées par phase par rapport à des tests de fixtures ; les builds incrémentaux sont vérifiés dans un test en mode mixte.
• Les suites de build mesurent sur un petit corpus en vérifiant des chemins de code (empreinte, minification, analyses de liens, schéma) et confirment les conditions de data races et de temps mur (via des exemples build_speed_4637 : les idées de régression à vitesses multiples).

Comportements air-gap et plateforme

• Comportements d'e-mail avec air-gap désactivé (admin_email_airgap.t), chemins d'échec SMTP (admin_email_smtp.t, form_email_smtp_fail.t) et vérifications CRLF sur le SMTP artisanal forcé (form_email_crlf.t).
• Garde Turnstile : derrière les réglages turnstile_*, vérifie les panneaux comme une suite séparée (turnstile_gate.t).
• Ports tournés vers l'amont du routage d'URL, de l'échappement XML (sûreté du sitemap et des feeds) et de la vérification d'instructions dans les gardes d'ombrage de routes.

Le mélange de suites à connaître

• La suite des migrations vérifie l'unicité de chaque fichier de migration lorsqu'il est rejoué sur une base temporaire (idempotence/rejeu sûr) et recoupe migrations et schéma pour que schema.sql et les migrations ne puissent pas diverger (migrations_lint.t, migrations_has_table.t, migrations_helpers.t).
• Les tests d'installation (installer-install.t, installer-bundle.t) couvrent le chemin d'installation par bundle hors ligne.
• zz_phase80_verify.t s'exécute en dernier (dernier par ordre alphabétique) comme couche de vérification traversant plusieurs domaines.

Dans cette section

• Exécuter la suite de tests
• Référence du helper de tests