Qu'est-ce que les tests de régression visuelle ? Des captures d'écran comme assertions

Le test de régression visuelle prend une capture d’écran de votre interface, la compare à une capture approuvée d’avant, et échoue quand des pixels ont changé sans que personne n’ait accepté ce changement. C’est le seul type de test qui attrape une modification de feuille de style déplaçant un bouton de quatre pixels vers la gauche, parce que ce n’est pas un comportement qu’une assertion allait un jour décrire.

Tout le reste découle d’un fait gênant : une capture d’écran n’est pas déterministe, et un test qui n’est pas déterministe finira par être ignoré.

Ce que produit une exécution

Trois images par vérification, et la troisième est la seule que quelqu’un regarde.

• La référence - la capture approuvée, versionnée avec le code.
• La candidate - ce que l’interface rend maintenant.
• Le diff - les deux superposées, avec les pixels modifiés marqués.

Une vérification passe quand la candidate correspond à la référence, et échoue sinon. Échouer n’est pas la même chose qu’avoir tort : une refonte volontaire fait échouer toutes les vérifications qu’elle touche, et le correctif consiste à approuver les nouvelles captures comme références. C’est dans cette étape d’approbation que se trouve le vrai travail.

Les échecs qui n’en sont pas

Presque tout ce qui est difficile ici, ce sont les faux positifs, et ils viennent d’une courte liste des mêmes causes.

• L’anticrénelage et le rendu des polices. Le même texte sur deux machines, ou avec deux pilotes graphiques, ce ne sont pas les mêmes pixels.
• Tout ce qui affiche l’heure actuelle. Un horodatage, un “il y a 3 jours”, une année de copyright.
• Les données dynamiques. Une liste triée par date, un nom tiré au hasard d’une fixture, un nombre qui grandit.
• Les animations et les transitions. Une capture prise au milieu d’une transition est un tirage à pile ou face.
• Les polices qui arrivent en retard. La capture est prise avant le chargement de la webfont, donc la référence a une typographie et la candidate une autre.
• Les barres de défilement. Différentes d’un système d’exploitation à l’autre, et souvent à l’intérieur de la zone capturée.

Chacune a un correctif ennuyeux : figer l’horloge, remplacer les données par des données fixes, désactiver les animations, attendre que les polices se stabilisent, et faire chaque capture dans un seul environnement maîtrisé plutôt que sur la machine qui se trouve être libre. Docker est la réponse habituelle au dernier point, et c’est la plus grosse source de bruit si vous le sautez.

Autrement dit, une suite visuelle est un problème de tests instables avec un autre chapeau. La même règle s’applique : une vérification qui échoue pour des raisons étrangères au code cesse d’être lue, et une suite que personne ne lit est pire que pas de suite du tout, parce qu’elle coûte toujours du temps.

Les seuils sont le mauvais premier réflexe

La réponse évidente au bruit est d’autoriser un pourcentage de pixels différents. Ça marche, et c’est aussi comme ça qu’un vrai défaut passe.

Faible

Échouer si plus de 0,5 % des pixels diffèrent - ce qui laisse largement la place, sur une grande page, à un bouton qui se déplace, un prix qui change ou un libellé de formulaire qui disparaît

Mieux

Tolérance zéro, avec des régions exclues nommées : l'horloge de l'en-tête, l'avatar, le graphique qui se redessine. Chaque exclusion est une décision que quelqu'un a écrite

Un seuil global est une déclaration disant qu’une fraction inconnue de votre interface peut changer sans vous le dire. Une région ignorée est une déclaration sur un élément précis, relisible dans une pull request, et elle ne grandit pas discrètement à mesure que la page s’agrandit.

Ce qu’il ne peut pas vous dire

Il ne peut pas vous dire qu’un changement est mauvais. Il vous dit qu’un changement a eu lieu, et c’est une personne qui décide lequel des deux c’est.

Cela semble une petite nuance jusqu’à ce que vous comptiez les relectures. Chaque changement visuel volontaire produit une file de diffs que quelqu’un doit regarder et approuver, et si cette personne n’est pas nommée, la file devient un tampon automatique en un mois. À partir de là, la suite tourne, elle est verte, et elle ne vaut rien.

Il ne vérifie par ailleurs que ce sur quoi vous l’avez pointé, dans les navigateurs et les tailles de fenêtre dont vous lui avez parlé. C’est l’angle mort qui mérite d’être nommé, parce que c’est là que vivent les bogues intéressants. Une mise en page qui casse seulement sous Safari, ou seulement à 320 pixels de large, ou seulement quand le navigateur n’arrive pas à décoder la vidéo que vous servez, est invisible pour une suite qui capture Chrome à une seule taille.

Quand il vaut son prix

Le motif, c’est la répétition. Le test visuel est rentable là où les mêmes composants sont rendus de nombreuses fois, d’une façon qu’une personne ne peut pas revérifier en pratique.

Un design system ou une bibliothèque de composants est le cas le plus fort : un changement de padding touche tout, et la suite vous dit exactement ce qu’il a touché. Les pages marketing sont le deuxième, parce qu’elles sont surtout de la mise en page et qu’une page cassée coûte directement de l’argent. Tout ce qui est rendu en plusieurs langues ou thèmes est le troisième

• la même page en sept langues, ce sont sept occasions pour une traduction d’être plus longue que son conteneur, et personne n’ouvre les sept à la main à chaque livraison.

Il rapporte beaucoup moins sur une interface qui est refondue toutes les semaines, où chaque exécution est un mur d’approbations, et sur des écrans internes où un défaut cosmétique coûte à quelqu’un un haussement d’épaules.

Où il se situe par rapport au reste

Le test de régression visuelle, c’est du test de régression avec une capture d’écran comme assertion, donc la même logique décide de ce qui y a sa place : des choses qui marchaient et doivent continuer à marcher. Votre plan de test devrait dire quelles pages sont couvertes et, plus utile encore, lesquelles ne le sont pas.

Ce n’est pas non plus la même chose que le signalement visuel de bogues, malgré le mot commun, et les deux répondent à des questions opposées. Une suite visuelle trouve un changement non voulu avant que quiconque le voie, dans les environnements que vous avez choisis. Un rapport de bogue vous dit ce qui a mal tourné pour une personne réelle, dans le navigateur qu’elle a vraiment, sur la page qu’elle utilisait vraiment. Aucun ne remplace l’autre : le premier est un filet, le second est ce que vous faites du poisson qui est passé au travers.

Nous ne vendons pas d’outil de test visuel, et c’est la limite honnête de ce que nous pouvons vous dire sur le fait d’en faire tourner un. Ce que nous voyons, c’est l’autre bout - le rapport qui arrive parce que quelque chose s’est mal affiché pour quelqu’un, sur un navigateur ou une taille d’écran que personne n’a capturés.

Un point de départ qui survit au contact

Cinq pages, un navigateur, une taille de fenêtre, exécutées en CI sur chaque pull request, dans un conteneur pour que les pixels soient stables. Une personne nommée approuve les diffs. Des régions exclues plutôt qu’un pourcentage.

Ajoutez des navigateurs et des tailles quand les cinq pages sont vertes et dignes de confiance depuis un mois. La plupart des suites abandonnées étaient trop larges dès le premier jour, et celles qui survivent ont commencé plus petites que ce qui semblait sérieux.