Référence du helper de tests

t/helper.pl est la bibliothèque partagée de la suite de tests : le constructeur de fixtures et les utilitaires de connexion que chaque fichier de test utilise. Cette page est la référence côté programmeur pour les pièces qu'il fournit. (Pour savoir comment exécuter la suite, voyez la page running-tests ; pour ce qui est testé, voyez la page de couverture.)

setup_test_env

Le constructeur d'environnement, appelable depuis n'importe quel fichier de test :

• Fixe le secret de session à une valeur de test connue et MOJO_MODE=test (la branche mode test du CMS exécute le travail différé de manière synchrone, pour que les tests n'attendent pas des minuteries).
• Crée une base SQLite temporaire neuve (File::Temp, UNLINK-du-seul-fichier-principal) construite instruction par instruction depuis le vrai schema.sql, avec les sections INSERT d'amorçage pour users et settings retirées, pour que les amorces de la suite fassent autorité.
• Active l'application des clés étrangères (PRAGMA foreign_keys = ON).
• Pointe CHINASKI_DB vers le fichier temporaire, CHINASKI_DOCS_DIR vers un chemin imbriqué par exécution (<db>.docs/documents), et crée le répertoire output/ de l'app s'il manque (il est gitigné ; des checkouts frais sur la CI échoueraient sinon à la vérification répertoire-de-sortie-inscriptible du /health dans les tests qui l'exercent).
• Enregistre le nettoyage dans un bloc END : les sidecars -wal/-shm du WAL et l'arbre de docs, que les astuces d'unlink de SQLite n'attrapent jamais.
• Amorce deux utilisateurs avec des mots de passe hachés bcrypt générés à l'exécution via Crypt::Passphrase (admin/admin123, editor/editor123) et un site à deux langues (en, es).
• Finalement charge la vraie application (require cms.pl) et expose le harnais comme $t = Test::Mojo->new (globales de package partagées, pour que chaque test puisse faire $t->get_ok(...) juste après l'appel).

login_admin / login_editor

Pilotent une connexion complète :

1. GET /login (200).
2. Extraire le token CSRF du formulaire rendu (csrf_token" ... value="…") via une regex, à l'image de la façon dont le CSRF de connexion est validé côté serveur.
3. Poster les identifiants avec le token, attendre la redirection 302, puis affirmer que l'en-tête Location correspond à la zone d'admin (l'app peut rediriger vers un chemin return_to enregistré quand la connexion a été précédée d'une URL protégée, c'est pourquoi le test n'affirme que le préfixe).

Les autres éléments exportés

• $t et $dbh sont des globales de package pour que les tests puissent piloter des appels HTTP ou atteindre directement la base quand c'est nécessaire.
• Les fonctions helper sont des noms exportés via la liste de modules (setup_test_env, login_admin, login_editor, $t, $dbh).

Conventions

• Les fichiers qui ont besoin du harnais appellent setup_test_env() juste après avoir use/require helper.pl ; tout ce qui précède cet appel n'a ni app ni base.
• Les mutations d'état locales doivent rester dans la propre session du fichier de test ; le harnais ne réinitialise rien entre les tests d'un même fichier (c'est de l'isolation par fichier, pas par assertion).
• Les tests qui passent la main au shell pour le build fixent CHINASKI_TEST=1 eux-mêmes ; le helper ne le fait pas.