Stratégie de tests
Stratégie de tests — @legba-core
La rigueur des tests est la contrainte structurante du projet. Aucun billet n’est validé sans que les niveaux applicables soient verts.
Les cinq niveaux
| Niveau | Outil | Portée | Seuil |
|---|---|---|---|
| Unitaire | Vitest | Une fonction, une classe, sans entrée/sortie réelle | Couverture de branches ≥ 90 % |
| Mutation | Stryker | La qualité des tests unitaires eux-mêmes | Score de mutation ≥ 80 % |
| Intégration | Vitest + Testcontainers | Legba ↔ LiveKit, ↔ Redis, ↔ base de données, réels | Tout chemin critique couvert |
| Composant | Web Test Runner + Playwright | Un Web Component isolé, dans un vrai navigateur | Tout composant public couvert |
| Bout en bout | Playwright | Un parcours utilisateur complet, sur une instance déployée | Tout parcours du backlog couvert |
Ce que chaque niveau doit prouver
Unitaire
- Les erreurs typées sont levées dans chaque cas d’échec, pas seulement le cas passant.
- Les valeurs limites : chaîne vide, zéro participant, jeton expiré, salle inexistante.
- Aucun appel réseau : les adaptateurs sont remplacés par des doubles.
Mutation
- Le score sous 80 % fait échouer la construction. Un test qui ne meurt pas quand on casse le code ne teste rien.
- Les mutants survivants sont soit tués par un nouveau test, soit justifiés par écrit dans le billet.
- Portée :
@legba-core/core,@legba-core/realtime. Les enveloppes triviales de SDK sont exclues, la liste d’exclusions est explicite et relue.
Intégration
- Un vrai serveur LiveKit dans un conteneur, jamais un double.
- Les jetons sont vérifiés par le serveur, pas par une assertion locale.
- Les webhooks sont reçus réellement, pas simulés.
- Les cas de panne : serveur indisponible, jeton refusé, reconnexion après coupure réseau.
Composant
- Chaque Web Component public : état initial, état de chargement, état d’erreur, état vide.
- Accessibilité vérifiée automatiquement (axe-core) : contraste, rôles, étiquettes, ordre de tabulation.
- Le thème par variables CSS est appliqué et vérifié.
- Rendu testé dans Chromium, Firefox et WebKit.
Bout en bout
- Deux navigateurs réels dans la même salle, média factice activé.
- Parcours minimal : rejoindre, publier le micro et la caméra, voir l’autre participant, envoyer un message, quitter.
- Parcours d’enregistrement : démarrer, arrêter, récupérer l’artefact.
- Aucune attente fixe : uniquement des attentes sur condition.
Portes de qualité en CI
Dans l’ordre, chaque étape bloque la suivante :
- Limite de 500 lignes par fichier source
- Lint et vérification des types
- Tests unitaires + seuil de couverture
- Tests de mutation + seuil de score
- Tests d’intégration
- Tests de composant
- Tests bout en bout
- Documentation MCP présente et à jour pour tout module modifié
Une étape rouge interdit la fusion. Aucune exception, aucun contournement temporaire.
Règles d’écriture des tests
- Un test porte le numéro de son billet :
LGB-011 · une salle fermée refuse toute nouvelle connexion. - Le nom du test décrit le comportement attendu, jamais le nom de la méthode testée.
- Un test, une assertion de comportement. Pas de test fourre-tout.
- Aucune donnée aléatoire non semée : un échec doit être reproductible.
- Les fichiers de test comptent dans la limite de 500 lignes : au-delà, découper par comportement.