Tests UI avec Puppeteer : le guide pratique

Ce que les tests UI avec Puppeteer font vraiment bien

• Le contrôle direct du navigateur. Captures d'écran, PDF, interception réseau, traces de performance. Quand vous avez besoin que le navigateur fasse quelque chose de précis, c'est le chemin le plus court.

• Le scraping et l'automatisation. Une grande partie des usages de Puppeteer n'a rien à voir avec les tests, et il y excelle.

• Une surface réduite et facile à apprendre. Vous pouvez garder toute l'API en tête, ce qui est plus rare que ça ne devrait l'être.

Les trois coûts d'une suite de tests navigateur

• Les sélecteurs cassent. Une refonte qui ne change rien au fonctionnement fait passer la suite au rouge. C'est là que part l'essentiel du temps de maintenance.

• L'attente est subtile. Les délais fixes sont lents et restent instables ; une attente correcte suppose de savoir quoi attendre. La plupart des tests instables viennent de là.

• La couverture est écrite à la main. Vous couvrez ce que quelqu'un a écrit, c'est-à-dire les parcours qui semblaient intéressants plutôt que ceux qui cassent.

Décider quoi automatiser

L'instinct pousse à commencer par la fonctionnalité la plus importante. Un meilleur critère : le silence avec lequel une panne passerait. Un tunnel de paiement qui casse fait du bruit, et vous serez au courant dans l'heure. Un export, une invitation ou une page de paramètres qui casse, c'est silencieux — et ce sont les pannes silencieuses qu'il vaut mieux automatiser en premier.

Deuxième critère : la fréquence des changements. Un parcours qui change à chaque sprint coûtera plus en maintenance qu'il ne rapporte. Couvrez-le plus tard, une fois qu'il s'est stabilisé.

Trois habitudes qui font gagner le plus de temps

• Utilisez des attributs stables. Un attribut de test dédié plutôt qu'un chemin CSS. À elle seule, cette habitude élimine l'essentiel des casses liées aux refontes.

• Attendez un état, pas un délai. Attendez l'élément ou la réponse, jamais un nombre de millisecondes.

• Vérifiez quelque chose qu'un rechargement confirmerait. Une notification de succès ne prouve pas que quoi que ce soit a été enregistré.

La place de la vérification par intention

Les casses de sélecteurs et la couverture écrite à la main sont des problèmes structurels, et non des problèmes de discipline. Une étape exprimée sous forme d'intention survit à une refonte à laquelle un sélecteur ne survit pas, et une couverture générée à partir de votre produit plutôt que de la mémoire de quelqu'un inclut des parcours que personne n'aurait écrits.

Ce n'est pas un argument contre Puppeteer, qui reste le bon outil pour le contrôle direct du navigateur. C'est un argument pour ne pas écrire l'étendue à la main.

Si vous préférez ne rien installer, le tableau de bord fait la même chose. Tout ce que la ligne de commande sait faire d'autre se trouve dans le dépôt CLI.

Les trois choses qui rendent un script Puppeteer fragile

Les scripts écrits à la va-vite cassent pour les trois mêmes raisons, et chacune a une correction qui ne coûte rien sur le moment et cher plus tard.

Les chemins CSS enchaînés arrivent en premier. Un sélecteur qui traverse quatre niveaux de structure encode la mise en page plutôt que l'élément : le moindre conteneur ajouté par qui que ce soit le casse. Ancrez-vous sur quelque chose qui décrit ce qu'est l'élément, pas l'endroit où il se trouve.

Les attentes fixes viennent en deuxième. Un délai assez long pour être fiable un jour de lenteur est un délai que vous payez tous les jours rapides, et il échoue quand même le jour le plus lent. Attendez l'élément, la réponse ou le changement d'état.

Vérifier ce que vous venez de faire arrive en troisième. Cliquer sur « enregistrer » puis constater que le bouton d'enregistrement existe ne prouve rien. L'assertion doit porter sur quelque chose qui ne devient vrai que si l'opération a réellement abouti, ce qui suppose généralement d'aller récupérer l'objet.

À exécuter à chaque changement

Si le pipeline appartient à une autre équipe, la GitHub App est la voie de moindre résistance : c'est un webhook, elle ne change rien dans votre dépôt, et elle se déclenche quand votre build signale la mise en ligne de la nouvelle version. Si vous préférez que la vérification soit visible dans le dépôt, une étape GitHub Actions s'en charge.

La place de TestSprite aux côtés de Puppeteer

Puppeteer reste en place pour le contrôle direct du navigateur : captures d'écran, PDF, interception réseau, scraping. TestSprite prend la partie qui ne passe pas à l'échelle avec le temps d'écriture humain, à savoir décider quoi couvrir et maintenir le tout en vie.

Les étapes sont enregistrées sous forme d'intentions plutôt que de sélecteurs, ce qui élimine l'essentiel des casses liées aux refontes, et l'attente est gérée pour vous au lieu d'être un réglage à ajuster test par test. La couverture est générée à partir de votre produit : les parcours silencieux qui n'arriveraient jamais sur la liste de qui que ce soit en font partie.

Ce que cela change en pratique : la proportion de builds en rouge qui correspondent à de vrais bugs reste assez élevée pour que les gens continuent de les lire, et c'est ce qui détermine réellement si une suite de tests navigateur survit à sa deuxième année.