Tester un monorepo de 48 packages à grande échelle

Ahnii!

Contexte de la série : Il s'agit de la partie 9 de la série Waaseyaa. Les articles précédents couvraient le système d'entités, le contrôle d'accès, la couche API, la migration DBAL et i18n.

Waaseyaa dispose de 48 packages, 7 couches architecturales et 3 applications consommatrices. Cela représente une grande surface à tester. Si chaque test nécessite une base de données en cours d'exécution, un conteneur DI complet et un serveur Web, la suite prend quelques minutes et s'arrête constamment. Les tests irréguliers érodent la confiance. Les tests lents tuent l’élan.

Cet article couvre la stratégie de test qui permet au monorepo de fonctionner : des implémentations en mémoire pour la vitesse, un plan de test en couches pour la couverture et une génération assistée par l'IA pour le volume.

Le problème des tests à grande échelle

Un monorepo multiplie les défis de test habituels. Modifiez une signature de méthode dans le système d'entités et vous risquez de rompre le contrôle d'accès, la couche API et deux applications consommatrices. Exécutez chaque test sur une base de données réelle et vous attendez trois minutes pour obtenir un retour sur une modification d'une ligne.

L'objectif est de réaliser des tests unitaires rapides et isolés qui détectent immédiatement les erreurs logiques, avec des tests d'intégration plus lents qui détectent les bogues multi-packages manqués par les tests unitaires. Chaque niveau a un travail. Aucun niveau n'essaye de tout faire.

Imp...
[Courte citation de 8% de l'article original]