Exécuter la suite de tests

Chinaski embarque son propre harnais de tests : t/ plus le bootstrap partagé t/helper.pl. Environ 120 fichiers de tests, tous exécutables avec une seule commande.

En une ligne

CHINASKI_SECRET=ci-test-secret prove -lr t/

C'est la même invocation que celle utilisée par la CI du projet (prove -lr t/ à chaque push et chaque PR vers main), avec le secret fixé dans l'environnement de la CI. Les fichiers individuels s'exécutent à la demande : perl t/pages.t ou prove -l t/pages.t.

Ce que helper.pl fournit

Les fichiers de tests se bootstappent sans boilerplate :

setup_test_env fixe le secret de session et MOJO_MODE=test, construit une base SQLite temporaire neuve depuis le vrai schema.sql, pointe CHINASKI_DB vers elle, et fixe un répertoire de documents par exécution pour que les fichiers temporaires ne se percutent jamais entre utilisateurs ni entre exécutions. Elle précrée aussi le répertoire de sortie de build (gitignoré) pour que la vérification de sortie inscriptible du /health n'échoue pas comme faux positif sur un checkout frais.
Le nettoyage est enregistré: un bloc END retire les sidecars WAL de la base temporaire et le répertoire de docs par exécution. Les deux s'accumulaient entre les exécutions sur la propre machine du projet avant ce correctif, donc le nettoyage est porteur.
Données d'amorçage: deux comptes (admin/admin123 avec le rôle admin, editor/editor123 avec le rôle éditeur) contre un site à deux langues (en, es), hachées bcrypt au moment de l'installation.
Les helpers de connexion accomplissent tout le flux de connexion : récupérer la page de login, extraire le token CSRF, poster les identifiants, atterrir dans /admin.
L'application testée est la production cms.pl elle-même chargée dans un harnais Test::Mojo (avec le flag Secure du cookie de session désactivé pour la boucle de tests non HTTPS) ; la suite teste toujours le code livré, jamais un stub.

Obtenir l'accès dans les tests

login_admin et login_editor gèrent les détails, y compris l'extraction du token CSRF depuis la page de login rendue. Les tests qui ont besoin d'un contrôle plus fin peuvent atteindre les routes directement avec les helpers de token.

Prérequis d'environnement

Le même ensemble de dépendances que l'app (Perl 5.26+, Mojolicious, DBI/DBD::SQLite, Template, Imager, DateTime, modules Crypt, sqlite3 pour l'installation de la base).
Le workflow de CI sert aussi de documentation de la recette de provisionnement côté hôte (bibliothèques système plus une liste d'installation cpanm), et tourne sur un runner auto-hébergé colocalisé avec l'hôte de déploiement ; les dépendances sont provisionnées une fois au niveau système, pas à chaque exécution.

Le serveur MCP testé séparément

chinaski-mcp/mcp.t est la propre suite du serveur MCP. Elle fixe le CHINASKI_API_URL/CHINASKI_API_KEY requis par test (le serveur refuse de démarrer sans les deux) et teste le comportement du protocole face à l'API de manière isolée.

Conventions à connaître

Les fichiers de tests qui passent la main au builder fixent CHINASKI_TEST=1, parce que le builder sinon refuse de tourner en root.
Les fichiers préfixés numériquement (00-compile.t, 01-schema.t, 02-media-sniff.t, 03-util.t, 04-webhook.t) jouent le rôle de vérifications de pré-vol : un build cassé ou un changement de schéma y fait surface en premier lors d'une passe prove -lr t/, avant tout test de fonctionnalité.
La suite est développée pour Linux (le runner de CI est Linux ; la CI exécute la même chaîne d'outils que les déploiements de production).