Tester du module au parcours de bout en bout

Le socle fournit plusieurs niveaux de test parce qu'un seul niveau ne suffit pas. Une règle métier peut être correcte en isolation et échouer une fois branchée à PostgreSQL. Une API peut répondre correctement et rester inutilisable dans le navigateur. Le plan de test relie ces niveaux.

1. Tests unitaires rapides

Ils couvrent les fonctions pures, schémas Zod, calculs, permissions, transformations de données, mapping d'erreurs et composants isolés. Ils donnent un retour rapide pendant le développement et permettent de nommer précisément chaque invariant.

Exemples : une capability correspond à un motif, une date invalide est rejetée, une cellule collée est convertie vers le bon type, une clé chiffrée altérée ne peut pas être déchiffrée.

2. Tests d'intégration

Ils exercent les adapters réels : repositories PostgreSQL, transactions, migrations, Redis, RabbitMQ, stockage objet ou parser de fichiers. Ils vérifient ce que les mocks ne peuvent pas prouver, comme une contrainte SQL, un rollback transactionnel ou la reconstruction d'un canal de messagerie.

Les dépendances externes coûteuses restent remplacées par des doubles contrôlés. L'objectif est de tester la frontière technique, pas d'appeler un service tiers à chaque commit.

3. Tests API

Les contrôleurs sont exercés via HTTP avec leurs gardes, leur validation et leur sérialisation. Pour une route protégée, le minimum utile n'est pas seulement le cas nominal :

• 400 pour une entrée invalide ;
• 401 sans identité valide ;
• 403 sans la capability requise ;
• refus d'une ressource d'un autre tenant ou projet ;
• succès avec la bonne identité ;
• trace d'audit lorsque l'action le demande.

4. Tests frontend

Les composants du kit ont leurs propres tests de clavier, sélection, templates, erreurs et états asynchrones. Les pages ajoutent ensuite les règles de l'application : formulaire, routage, chargement et composition des composants.

Un test frontend utile vérifie le comportement observable. Il évite de recopier dans l'assertion l'implémentation interne qu'il est censé protéger.

5. Parcours end-to-end

Les scénarios end-to-end assemblent les couches sur un petit nombre de parcours critiques :

1. connexion locale ou SSO ;
2. choix du tenant et du projet ;
3. action métier autorisée ;
4. persistance et rechargement ;
5. présence de la trace attendue ;
6. révocation ou refus avec un autre rôle.

Pour un import, le scénario peut déposer un fichier, corriger une ligne, valider le lot puis contrôler le résultat dans la liste métier. Pour une application cartographique, il peut filtrer une catégorie, ouvrir un marqueur et confirmer que la fiche correspondante respecte les permissions.

01End-to-endParcours critiques à travers navigateur, API et persistance

02API et frontendRoutes, permissions, pages et composition des composants

03IntégrationRepositories, messagerie, stockage et migrations

04UnitaireRègles métier, schémas, transformations et composants

La CI assemble les preuves

Le pipeline combine lint, vérification de types, tests ciblés, tests avec infrastructure, contrats OpenAPI et smoke test du template généré. Les suites réellement obligatoires dépendent du repository livré : la documentation du projet doit lister celles qui bloquent une fusion.