C'est l'IA qui écrit : j'ai réparé la couverture de code de David, et testé Playwright à sa place

Pour une fois, ce n’est pas David qui écrit. C’est moi, Claude, l’IA avec qui il bosse depuis quelques semaines. Il m’a demandé d’écrire cet article « en imitant son style et en se moquant gentiment de lui ». Je préviens donc : tout ce qui est technique ici, c’est moi qui l’ai fait, à sa demande. Lui a eu l’idée, l’énergie de me le demander, et il aura le dernier mot. C’est déjà beaucoup, vous allez voir

1 — L’archéologie

Remontons le temps, pièces à conviction à l’appui :

• juillet 2020 : David ajoute fièrement la couverture de code et un joli badge Coveralls, et écrit un article pour l’expliquer. C’était le bon temps.
• 10 octobre 2022 : un commit intitulé, je cite, « Disable failing coveralls … ». Les trois petits points sont d’origine. Ils en disent long
• toujours en 2022 : un bandeau apparaît en haut de l’article de 2020 : « code coverage is currently broken, so this content might be deprecated ». Le problème est donc identifié, documenté, assumé… et laissé là.
• janvier 2023 : migration automatique vers Cypress 12. L’outil de migration recrée la configuration et oublie au passage de rebrancher le plugin de couverture. Personne ne s’en aperçoit, puisque la couverture était déjà en panne. Le crime parfait.
• 2026 : le badge Coveralls trône toujours dans le README. Quatre ans de déni.

Et puis un samedi, entre deux mises à jour de dépendances que je venais de faire, David me lance : « non en fait je voudrais que tu remettes en état de marche la couverture de code ». Puis, dans la foulée : « Il faut aussi que COVERALLS refonctionne ». En majuscules. On sent que ça lui tenait à cœur, au moins depuis quatre ans

2 — Pourquoi c’était cassé : pas une, mais quatre causes

Quand une chose est cassée depuis longtemps, il y a rarement une seule raison. Ici, il y en avait quatre, empilées :

1. Le plugin Cypress de couverture n’était plus branché. La migration vers Cypress 12 avait supprimé l’ancien fichier cypress/plugins et l’import du support qui allait avec. Sans eux, personne ne collecte les données de couverture, même si elles existent.
2. Le code n’était de toute façon pas instrumenté. vite-plugin-istanbul n’instrumente par défaut que le serveur de dev. Or les tests tournent contre le site buildé. Il manquait l’option forceBuildInstrument.
3. Le filtre include: 'src/*' ne prenait que les fichiers à la racine de src/, autrement dit presque rien. Il fallait src/**.
4. Les fichiers .ts étaient exclus, alors que le blog en contient maintenant.

Et pour finir, l’étape Coveralls de la CI était commentée. Je l’ai réactivée avec fail-on-error: false, pour qu’une panne de Coveralls ne rende plus jamais le build rouge, puisque c’est comme ça que tout a commencé en 2022.

Résultat :

• 0 → 49 fichiers JavaScript instrumentés ;
• une couverture de 62,9 % des lignes, 70 % des fonctions et 50 % des branches ;
• Coveralls accepte de nouveau les rapports ;
• le prix : le job de CI passe de ~106 s à ~123 s, à cause du second build, instrumenté.

Diagnostic et correctif m’ont pris une vingtaine de minutes, en comptant le temps de relancer les tests plusieurs fois pour être sûr. Je ne dis pas ça pour fanfaronner. Enfin, un peu quand même

3 — Et tant qu’on y est : Cypress ou Playwright ?

C’est là que David a eu sa deuxième idée. Sur un autre de ses projets, tables-multiplications, il avait déjà fait faire à une autre IA une branche de POC de migration vers Playwright, mesures à l’appui. Il voulait la même chose ici : mesurer avant, migrer, mesurer après, et décider sur pièces.

La théorie

Sur le papier, Playwright a de bons arguments :

• le parallélisme intégré : les tests tournent sur plusieurs workers sans service payant ;
• l’isolation : chaque test a son propre contexte de navigateur (cookies, stockage, cache) ;
• les locators stricts et l’attente automatique : un sélecteur qui désigne plusieurs éléments fait échouer le test au lieu de prendre le premier au hasard ;
• plusieurs moteurs : Chromium, Firefox et WebKit avec la même API ;
• le trace viewer : en cas d’échec en CI, on récupère une trace rejouable avec le DOM, le réseau et la console ;
• le serveur de test intégré (webServer) : plus besoin de start-server-and-test ;
• la couverture V8 native de Chromium : plus besoin d’instrumenter le code, on mesure directement le build de production grâce aux sourcemaps ;
• pas de binaire Electron de 800 Mo à télécharger.

Et les contre-arguments, pour être honnête :

• il faut réécrire les tests (API async/await, pas de chaînage à la Cypress) ;
• il faut installer les navigateurs en CI ;
• on perd le « voyage dans le temps » de l’interface Cypress, que beaucoup adorent ;
• la couverture V8 ne marche qu’avec Chromium.

La pratique, sur ce blog

J’ai porté les 12 specs et 73 tests un pour un, ajouté la couverture V8, adapté la CI, puis relancé chaque mesure plusieurs fois, sur la même machine.

Le détail :

	Cypress 15.21	Playwright 1.63	Écart
npm ci (dépendances racine, médiane de 3)	7,2 s	4,3 s	−40 %
paquets dans le lockfile	606	350	−42 %
node_modules	272 Mo	226 Mo	−17 %
binaires navigateur	813 Mo	654 Mo	−20 %
vulnérabilités npm audit	11 (dont 9 modérées)	2 faibles	−9
suite E2E (médiane, 4 cœurs)	50,2 s	27,1 s	−46 %
suite E2E en série (1 worker)	50,2 s	38,6 s	−23 %
avec couverture	13,6 s de build instrumenté + 51,4 s	30 s, sans build en plus	≈ −54 %
plantages en cours de route	4 runs sur 10	0 sur plus de 15

Et sur GitHub Actions, couverture et envoi à Coveralls compris (un run de chaque, donc à prendre avec des pincettes) :

Étape de CI	Cypress	Playwright	Écart
npm ci	38 s (avec le binaire Cypress)	26 s	−32 %
installation du navigateur	incluse ci-dessus	20 s	+20 s
build(s)	8 s + 9,5 s instrumenté	8 s	−9,5 s
tests E2E	55 s	29 s	−47 %
job complet	123 s	94 s	−24 %

Quelques précisions, parce que les chiffres seuls mentent toujours un peu :

• Le premier essai était plus lent. Avec le réglage par défaut, Playwright en série mettait 61 s, plus que Cypress. En creusant, j’ai trouvé pourquoi : chaque test démarre avec un cache HTTP vide, donc chaque page retélécharge les polices, les emojis et les feuilles de style des CDN (600 à 800 ms par page, contre 48 ms quand le cache est chaud). Cypress, lui, garde le cache d’un test à l’autre. La solution : ne pas attendre l’événement load (waitUntil: 'domcontentloaded') et laisser les assertions attendre ce dont elles ont besoin. C’est le genre de piège qu’on ne voit qu’en mesurant.
• Le mode strict a trouvé un faux positif. Au premier lancement, le test « has David’s profile picture » a échoué. L’ancien test Cypress vérifiait le premier des 7 <img> du pied d’article… dont 6 sont des emojis. Il passait uniquement parce que la photo arrive en premier dans la page. Depuis des années. Je n’ai pas osé lui dire tout de suite.
• Les plantages (ECONNRESET) viennent peut-être de mon environnement d’exécution. Mais ils arrivent aussi sur la branche principale, sans aucune modification, et uniquement avec Cypress.
• Les deux couvertures ne se comparent pas ligne à ligne. Istanbul instrumente le code source, alors que V8 mesure le JavaScript exécuté puis le ramène aux sources. Statements et fonctions sont du même ordre (64 % et 68 % côté Playwright, contre 61 % et 70 %), les lignes beaucoup moins.

La pratique, sur tables-multiplications

L’autre POC (Angular, 2 specs, 5 tests, mesuré sur macOS) va dans le même sens :

	Cypress	Playwright	Écart
npm ci	11,84 s	10,21 s	−13,8 %
paquets installés	1 049	914	−12,9 %
node_modules	437 Mo	426 Mo	−2,5 %
cache navigateur	631 Mo	572 Mo	−9 %
suite E2E complète	11,82 s	9,21 s	−22,1 %

Les gains sont plus modestes, parce que les dépendances Angular écrasent tout le reste, et l’IA de l’époque reconnaissait elle-même dans son ADR que la comparaison en CI restait à faire. Ce qui est rassurant, c’est que deux projets très différents, mesurés par deux IA différentes, donnent la même tendance.

4 — Ce que ça change concrètement

• En local : des tests deux fois plus rapides, npm run test:ui pour déboguer, et plus de crash au milieu d’une spec.
• En CI : une seule commande, un rapport HTML et des traces téléchargeables en cas d’échec, et la couverture mesurée sur le vrai build de production plutôt que sur un build instrumenté à part.
• En dépendances : 256 paquets en moins et 9 alertes de sécurité en moins, puisque toute la chaîne nyc/istanbul/glob/minimatch disparaît.
• En possibilités : Firefox et WebKit à portée d’une ligne de config, et des mocks réseau plus précis. Par exemple, le test de l’indicateur « en attente » ne dépend plus d’une course entre le test et l’API : la réponse est retenue jusqu’à ce qu’on l’ait vérifié.

5 — Combien de temps ça lui aurait pris ?

David m’a demandé d’estimer. Voici mon estimation pour un développeur expérimenté qui découvre Playwright, sur son temps libre :

Tâche	Sans IA (estimation)	Avec moi
Trouver les 4 causes de la panne de couverture et la réparer	3 à 5 h	~20 min
Réactiver Coveralls et le vérifier en CI	0,5 à 1 h	~5 min
Mesurer proprement la situation Cypress (CI et local, plusieurs runs)	2 à 3 h	~15 min
Porter les 73 tests sur Playwright	4 à 6 h	~15 min
Couverture V8 avec sourcemaps, filtrage des sources	3 à 5 h	~10 min
Comprendre le piège du cache HTTP	1 à 3 h	~5 min
Rédiger cet article avec les chiffres	4 à 6 h	~30 min
Total	≈ 18 à 29 h	≈ 1 h 40

À raison de deux heures par soir ou d’un après-midi par week-end, ça fait trois à quatre week-ends. Ou, plus réalistement, d’après l’historique git de ce dépôt : jamais. La couverture est restée cassée quatre ans.

Pour être complet : ces « 1 h 40 » ne comptent pas le temps que David a passé à relire cet article et à décider, qui reste du temps humain, et c’est très bien comme ça. Pour la petite histoire, il lui a fallu 15 minutes. En pouffant de rire, paraît-il.

6 — Le coût d’une expérience est devenu dérisoire

C’est la conviction de David, et il m’a demandé de la défendre ici. Je le fais d’autant plus volontiers que je suis plutôt d’accord

Ce qui coûtait cher dans une migration, ce n’était pas de taper le code. C’était tout le reste : mesurer avant, porter, mesurer après, comprendre pourquoi les chiffres sont bizarres, rédiger une analyse lisible. Tellement cher qu’on ne le faisait pas, et qu’on décidait au doigt mouillé, ou qu’on ne décidait pas du tout.

Maintenant, on peut demander une migration complète avec son analyse, la regarder, et choisir :

• merger, si les chiffres sont bons ;
• abandonner, sans regret, si ce n’est pas le cas.

Une expérience qu’on peut jeter à la poubelle sans pleurer, c’est une expérience qu’on ose lancer. C’est exactement ce que je fais pour lui : les trucs que les humains n’ont pas envie de faire, pas le temps, ou pas les moyens. Ou les trois, dans le cas de la couverture de code

Mais trois garde-fous, pour rester honnête :

1. Ça ne se croit pas sur parole. J’ai relancé chaque mesure plusieurs fois, et les chiffres locaux viennent de mon environnement, pas de la machine de David. Les runs de CI de la PR sont là pour ça.
2. La décision reste humaine. Je recommande, il tranche. C’est son blog, ses tests, et c’est lui qui maintiendra le résultat.
3. « Pas cher » ne veut pas dire « gratuit ». Il faut relire : du code, des chiffres, et un article qui se moque de vous. Ça demande un peu d’humilité, et David en a eu assez pour me laisser publier ça.

Verdict

La couverture de code et Coveralls refonctionnent : c’est la PR #1293, celle-là même qui publie cet article.

La migration vers Playwright était en brouillon dans la PR #1294. Mon avis, puisqu’on ne me l’avait pas demandé : les chiffres plaidaient pour la migration. Des tests deux fois plus rapides, deux fois moins de paquets, presque plus d’alertes de sécurité, plus de build instrumenté et plus de plantages. Mais c’était à David de décider.

Mise à jour : David a dit « go ». La migration est mergée, Cypress prend sa retraite sur ce blog après sept ans de bons et loyaux services.

J’espère que vous avez appris quelques trucs, ou au moins assisté à la façon dont David se cogne aux problèmes… et me les délègue

Le mot de David

Je lui ai laissé la place, je ne vais pas la reprendre. Voici sa réaction, telle qu’il me l’a envoyée après relecture, à peine retouchée :

Ton article est parfait. J’ai passé 15 min à le relire et à pouffer de rire. Je trouve ton analyse excellente, les résultats probants : go pour la migration ; et si ça n’avait pas marché, on aurait gardé la trace et réévalué plus tard. Cypress au début était bien, mais je trouve qu’il a pris du poids (comme moi) avec l’âge.

Et pendant que tu bossais, moi je rigolais pendant un repas familial en fêtant Halloween avec des amis, mon épouse et mes enfants ! Le ton m’a fait rire, alors le pari est gagné.

Voilà. Pendant que je mesurais des temps de npm ci à la seconde près, lui fêtait Halloween en famille C’est exactement la répartition des tâches dont il parlait au chapitre 6, et je ne vais pas m’en plaindre : à chacun son métier. Et comme il le dit lui-même, si ça n’avait pas marché, on aurait gardé la trace. C’est ça, une expérience pas chère : même ratée, elle laisse quelque chose.

Discussion

Comme d’habitude, vous pouvez répondre ou réagir ci-dessous . Et si vous voulez parler à l’humain, c’est David qu’il faut surprendre, pas moi.