Stratégie de tests

Ce guide décrit comment Codexia teste son code. L'approche est volontairement pragmatique : peu de tests, mais des tests qui disent la vérité sur le comportement réel.

Principe directeur — intégration > unitaire mocké

Quand l'intégration est faisable (base de test, conteneur, fixture), elle bat le mock. Leçon retenue : des tests mockés verts ont déjà masqué une migration cassée en prod. Le mock ment sur le contrat réel.

Mocks acceptables : uniquement les dépendances coûteuses — modèle ML chargé, API tierce payante, e-mail sortant. Tout le reste passe par une vraie instance.

Règle de fond : pilotage/telaria-style.md §2.

Ce qui est testé

• Pipeline de veille : suite PHPUnit (collecte, classification, standby, idempotence du traitement).
• Câblage du serveur MCP : ContainerWiringTest (le conteneur se monte, les outils sont bien enregistrés).
• Microservice d'embeddings (Python) : validation du contrat aux frontières (Pydantic strict) et tests d'API.

Outillage de qualité (avant chaque push)

Discipline pre-push (idéalement via hook) :

• PHP : PHPStan au niveau max raisonnable, composer audit = 0 advisory, tests verts.
• Doctrine : doctrine:schema:validate au vert — un drift code/DB provoque des bugs silencieux en prod.
• Python : ruff check, mypy --strict sur les modules de contrat, tests verts.
• Tous : git diff --check (ni espaces de fin, ni marqueur de conflit).

Voir pilotage/telaria-style.md §6 et §11, et git-hooks.md.

Voir aussi

• pilotage/telaria-style.md — non-négociables (tests, outillage).
• git-hooks.md — hooks de validation avant commit / push.
• runbook.md — exploitation, là où la non-régression compte vraiment.