Tests et conventions

En bref

Les tests automatiques protègent surtout les décisions métier, les droits d’accès et les effets de bord (emails, notifications, paiements), pas les textes ni la configuration. À chaque modification, la CI (intégration continue, la vérification automatique) lance les tests et corrige le style du code, mais ne déploie rien. Ce qui peut casser : un test vert peut tromper, parce que les tests et la production n’utilisent pas la même base de données. En cas de doute, les règles écrites dans le dépôt priment.

Fonctionnement

Ce qu’on teste

• Surtout des tests de parcours complets (requête, base de données, effets de bord), peu de tests isolés. Chaque test est rangé selon le portail ou le domaine qu’il couvre (courtier, admin, client, offre).
• On teste les décisions, les autorisations, les valeurs calculées et les effets de bord. On ne teste pas les textes, les simples déclarations ni la validation de base du framework.
• Changement de logique : on ajoute ou on met à jour un test. Changement de texte ou de style : aucun.
• Les données de test viennent de fabriques prévues pour ça. Les services externes (disques, appels réseau, pauses, monitoring, registres d’entreprises) sont remplacés par des simulations : un test ne contacte jamais un vrai service.
• Les tests tournent sur une base temporaire en mémoire, avec envoi d’emails simulé et files d’attente exécutées immédiatement.

Ce que fait la CI

Quand	Action
À chaque envoi sur la branche principale et à chaque demande de fusion	Installe le projet, compile le front, lance toute la suite de tests.
À chaque envoi qui touche du code PHP	Corrige le style et pousse un commit « Fix styling » : fais un git pull avant ton prochain envoi.
Chaque semaine	Dependabot propose une mise à jour côté PHP et une côté JavaScript, versions mineures et correctifs seulement.

La CI ne fait pas : de déploiement (le job s’appelle « test-and-deploy » mais ne fait que tester), de tests navigateur, de contrôle de style complet, d’analyse statique, de mesure de couverture. Ne jamais lui faire régénérer les clés de connexion de l’assistant IA : cela ferait tourner les vraies clés.

Règles et pièges

Pièges connus

• Base différente en test et en production. Les tests utilisent SQLite, la production PostgreSQL, et les identifiants sont des uuid. Certaines requêtes « dernier élément d’une relation » ou « minimum/maximum d’un identifiant » échouent en production alors que les tests restent verts. Pour toute nouvelle relation, agrégat ou requête brute : fige la requête générée dans un test, puis vérifie-la une fois sur la base de développement, en lecture seule ou dans une transaction annulée. Ne pointe jamais un test sur cette base. La suite complète ne peut pas tourner sur PostgreSQL.
• Slack. Les événements métier (nouvelle demande, police signée, paiement) notifient Slack, et pendant un test la notification partirait vraiment : simule-la au début de tout test qui déclenche un tel événement.
• Stripe. Dans les tests de parcours, remplace le service de paiement par une simulation. Pour les notifications de Stripe, utilise les faux messages fournis par les outils de test.

Conventions de code

• Suis les fichiers voisins, réutilise l’existant, pas de nouveau dossier racine ni de nouvelle dépendance sans accord. Lis d’abord les règles du dépôt : le front et les tests ont chacun leur fichier.
• Noms descriptifs, types explicites, commentaires courts (une ou deux lignes, le pourquoi seulement), imports toujours en haut du fichier.
• Aucun tiret cadratin nulle part, commits et docs compris.
• Une migration qui modifie une colonne répète tous ses attributs existants. Pas de SQL brut. Un nouveau modèle reçoit une fabrique de données et un jeu de démonstration.
• Côté front, les adresses sont écrites en dur (pas de génération automatique de routes). Un test vérifie chaque adresse courtier contre les routes réelles. Coût : renommer une route oblige à modifier le front à la main.
• Vocabulaire : les textes courtier disent « offre », jamais « quote » ni « dossier ». Un test interdit une liste de termes par langue (français, anglais, néerlandais), mais pas « quote » : relis ce point à la main et lis la liste avant de renommer un libellé. Les docs internes et les identifiants restent en anglais.
• Git : branche de fonctionnalité, demande de fusion, fusion dans la branche principale, qui est la production. Commit d’une phrase décrivant le comportement, sans ligne d’attribution d’outil d’IA.

Pour les développeurs : commandes et fichiers utiles

• Lancer le test le plus étroit : vendor/bin/sail artisan test --compact --filter=Nom, puis la suite complète.
• Avant de finir : vendor/bin/sail bin pint --dirty --format agent. Style complet : composer lint ; vérification seule : composer test:lint.
• Simuler Slack : Notification::fake() dans le beforeEach. Simuler Stripe : mock de PaymentService (findOrCreateCheckout), StripeWebhookPayloadFactory et invokeStripeWebhookController(). Registres : fakeCompanyRegistries().
• Réglages de test : phpunit.xml (SQLite en mémoire, QUEUE_CONNECTION=sync, MAIL_MAILER=array), tests/TestCase.php.
• Pas de MAX() ni MIN() sur une colonne uuid, ni latestOfMany() : voir les commentaires de app/Models/Policy.php.
• Test de vocabulaire : BrokerGlossaryTest. Test des adresses du front : tests/Feature/Broker/FrontendUrlsTest.php.
• Workflows : run-tests.yml (nom inqase-app), fix-php-code-style-issues.yml. Ne jamais ajouter passport:keys --force à la CI.

Où dans le code

• tests/Pest.php, tests/TestCase.php, .ai/rules/
• .github/workflows/run-tests.yml
• pint.json, rector.php

Questions ouvertes

• Comment sont produits les chiffres de couverture cités (86,8 % pour la plateforme), puisque la CI n’en mesure aucun ?