Politique de tests : Cerops

Principes

Les tests sont la spécification exécutable du système. Chaque procédure métier est couverte avant ou simultanément à son implémentation (TDD). Un test qui passe en CI est la définition de “fonctionne”.

Pourquoi les tests d’intégration sont faciles

oRPC expose les procédures métier comme des fonctions TypeScript ordinaires. Les tests les appellent directement, sans serveur HTTP à démarrer, sans mock réseau, sans sérialisation/désérialisation à traverser.

La base de données est une instance PostgreSQL + PostGIS réelle, éphémère par session de test, identique à celle de production (même schéma, mêmes types, mêmes contraintes). Ce que le test valide est exactement ce qui tourne en prod.

// Appel direct de la procédure, pas de fetch, pas de mock
const mission = await caller.missions.createMission({ plotIds, type, windowStart, windowEnd })

Chaque cas d’erreur (FORBIDDEN, UNAUTHORIZED, NOT_FOUND, CONFLICT) est testé explicitement, pas implicitement via des règles métier imprécises.

Structure

Un fichier de test par domaine métier dans packages/api/test/. La liste des fichiers reflète la liste des routers oRPC. Si un domaine n’a pas de fichier de test, il n’est pas couvert.

Tests E2E

Framework : Playwright · Localisation : packages/e2e/tests/

Flux d’authentification couverts. Les parcours utilisateur complets (web-agri, web-pilots) ne sont pas encore couverts.

Conventions de nommage

• describe : nom de la procédure oRPC (createMission, listPlots, etc.)
• test : phrase décrivant le comportement attendu, commençant par un verbe ou throws
  • Cas nominal : "creates mission with derived price and pricing config"
  • Cas d’erreur : "throws FORBIDDEN when called by a pilot"
  • Cas limite : "score floor: score cannot go below -20 after many cancels"

Ce qui n’est pas encore couvert

• Tests E2E des parcours utilisateur complets (web-agri, web-pilots) : uniquement auth pour l’instant
• Tests de charge / performance
• Tests de la couche mobile Flutter