Des tests E2E contre la vraie stack, pas des mocks

Les tests unitaires vérifient des fonctions ou des composants isolément, généralement avec les dépendances mockées. Playwright pilote un vrai navigateur contre l'application réellement en fonctionnement — cliquer, remplir, attendre la vraie réponse réseau — comme le fait un vrai utilisateur. Il attrape les défaillances d'intégration que les tests unitaires ne peuvent structurellement pas : front-end et back-end en désaccord une fois câblés ensemble, un flux d'authentification qui casse à travers une vraie redirection, tout ce qui n'apparaît qu'avec une vraie latence réseau.

Le job CI e2e lance de vrais conteneurs Postgres et Redis, construit le vrai back-end, exécute de vraies migrations contre une vraie base de test, construit les paquets front-end partagés, puis exécute Playwright contre la stack vraiment en fonctionnement — pas un back-end mocké, pas de réponses stubbées. Délibérément plus coûteux que mocker, parce que c'est le seul moyen d'attraper une classe de bug où le front-end et le back-end ont chacun l'air corrects seuls et sont en désaccord ensemble.

Le coût, c'est la vitesse et l'instabilité. Lancer une base, exécuter des migrations, construire des paquets et lancer de vrais serveurs est lent, et les attentes sensibles au timing, les conditions réseau et les transitions d'animation deviennent toutes des sources d'échec. C'est exactement pour ça que c'est son propre job CI plus long plutôt que mélangé aux jobs rapides de lint-et-typecheck — une suite lente et occasionnellement instable ne devrait pas bloquer la boucle de feedback rapide de chaque push.

E2E_START_SERVERS est un interrupteur propre à la CI qui dit au setup de démarrer les serveurs de dev dans le cadre de la campagne, plutôt que de supposer qu'ils sont déjà là — vrai pour le développement interactif local, jamais vrai sur un runner CI à froid. Ce genre d'interrupteur conscient de l'environnement est ce qui fait qu'une seule suite marche à la fois contre un serveur qu'un développeur a déjà ouvert et contre un démarrage complètement à froid.

Avec trois applications séparées, le setup doit décider lesquelles ont besoin de couverture et pointer Playwright vers la bonne base-URL pour chacune — une config codée en dur sur une seule URL ne couvrirait pas un flux qui s'étend sur plusieurs applications, comme une action du personnel dans admin qu'un client devrait ensuite voir reflétée dans web.

Sans personne d'autre qui relit les changements, c'est un des rares filets automatisés qui peut attraper un flux visible par l'utilisateur cassé avant qu'il n'atteigne la production. Cela dit — je me suis fait avoir à faire confiance à mes propres specs Playwright une fois, quand elles se sont révélées ne couvrir que des flux que j'avais déjà trouvés et corrigés. Une suite de non-régression est un relevé de bugs passés, pas une recherche de nouveaux.