Comment nous maintenons la qualité de votre académie à l'aide de tests de régression visuels

Récemment, nous avons présenté notre nouvelle interface académique. Au cours du développement, nous avons commencé à utiliser de nouvelles techniques pour nous aider à améliorer notre flux de travail et à maintenir un niveau de qualité élevé pour notre produit. Nous évitons les bogues en travaillant sur la base de composants et en testant souvent les changements visuels involontaires (régressions visuelles).

Développement axé sur les composants

Ces dernières années, le développement axé sur les composants (CDD) a constitué une tendance majeure dans le domaine du développement d'interfaces utilisateur. Les composants sont les plus petits éléments d'une fonctionnalité autonome, qui ajoutent de la valeur par eux-mêmes. Le CDD s'ancre dans ce principe en créant un processus de construction qui fonctionne de bas en haut. Vous créez d'abord de petits composants qui s'intègrent dans des composants plus importants qui, ensemble, constituent une fonctionnalité ou une page. Imaginez un vélo composé de petites pièces. Vous commencez par créer deux roues, puis un cadre. Ajoutez un volant, des pédales et une chaîne. Cela commence à ressembler à un vélo. C'est ainsi que nous avons développé l'interface de l'académie.

Nous tirons de nombreux avantages d'une méthode de travail axée sur les composants :

• Les composants sont réutilisables. Si vous construisez une roue, vous pouvez l'utiliser pour construire un vélo plus grand ou plus petit, ou peut-être même un tricycle.

• Les petits composants sont faciles à comprendre.

• Les composants sont facilement testables. Vous pouvez tester si la roue fonctionne, vous n'avez pas à vous préoccuper de l'ensemble du vélo pour l'instant.

• Le travail avec des composants accélère souvent notre processus de développement en fournissant des solutions prêtes à l'emploi.

• Le développement est ciblé. Il est facile de suivre les variations des composants.

• Il existe des outils permettant de suivre facilement tous les composants disponibles qui ont été créés par des collègues.

Voici quelques exemples de composants que nous avons créés : un bouton, une fenêtre contextuelle, une réponse à choix multiple et une page de connexion complète.

Storybook nous permet de développer des composants en dehors de notre application dans un environnement isolé, sans se soucier des dépendances ou de l'interruption de l'application.

L'histoire de notre interface dans Storybook

Après avoir créé de nombreux composants qui constituent l'épine dorsale de notre interface, nous les organisons dans Storybook. Storybook est un explorateur de composants, ou une bibliothèque de composants. C'est un moyen efficace de garder une trace de tous nos composants. Chaque composant a sa propre histoire dans Storybook, où toutes les variations possibles d'un composant peuvent être visualisées :  ;

Composant bouton dans Storybook

Pour un composant bouton, par exemple, il est possible de visualiser un bouton par défaut, un bouton surélevé, un bouton non surélevé et un bouton désactivé. Il est également possible d'interagir avec le composant pour voir comment cela modifie son état ou son comportement. Tapez quelque chose dans le formulaire de connexion, par exemple, et les champs de saisie vous indiqueront si la saisie est valide :

Composant de formulaire de connexion dans Storybook

Storybook nous permet de développer des composants en dehors de notre application dans un environnement isolé, sans se soucier des dépendances ou de l'interruption de l'application.

Nous utilisons Storybook comme outil de conception, car nous avons adopté une stratégie de conception axée sur l'histoire. Lorsque nous concevons, nous créons directement quelque chose qui a de la valeur. Au lieu de créer des transferts Photoshop inutiles comme nous le faisions auparavant. Lorsque nous ajoutons des histoires de composants à Storybook, nous contribuons automatiquement à un guide de style vivant, ou à une bibliothèque d'interface utilisateur. Cela signifie qu'un développeur peut facilement choisir parmi une vaste gamme de composantes préfabriquées pour les ajouter à une fonction qu'il est en train de créer. Cela permet à notre interface d'être cohérente et relativement peu coûteuse à développer :

Composant de page de connexion dans Storybook

À l'aide de modules complémentaires, nous avons étendu Storybook, afin de pouvoir tester l'accessibilité de chaque composant. S'assurer que l'interface reste accessible aux utilisateurs ayant certaines restrictions :

Vérification de l'accessibilité dans Storybook

Tests visuels de régression avec Percy

Nous avons parlé précédemment des régressions visuelles, c'est-à-dire des changements visuels involontaires. Pour prendre conscience de ces changements visuels, nous utilisons un outil appelé Percy. Percy est un outil de test de régression visuelle qui ne se préoccupe que de l'intégrité visuelle.

Avec Storybook, je peux construire et styliser des composants de façon isolée, et j'ai toujours une vue d'ensemble des différents scénarios que j'ai conçus. Avec l'aide de Percy, je connais toujours l'impact des changements que je fais.
Anouk
Front-End Developer & ; UX Designer

Pour chaque composant que nous avons développé dans notre bibliothèque de composants Storybook, une capture d'écran est réalisée. Lorsque nous modifions un composant, une nouvelle capture d'écran est réalisée et les deux sont comparées l'une à l'autre. Les différences sont alors marquées en rouge pour montrer clairement ce qui a changé:

Les régressions rendues visibles à Percy

Les différences entre l'ancienne et la nouvelle version sont marquées en rouge.

Percy est directement lié à notre pipeline d'intégration continue (le flux de l'idée à la réalité), en nous notifiant les régressions visuelles avant que les changements ne soient mis en ligne. Après un examen par l'un des concepteurs, les changements sont soit acceptés, soit refusés. Percy permet également de discuter d'un certain changement :

Percy s'est intégré dans notre pipeline en nous indiquant que quelque chose devait être revu.

Tout cela nous permet d'éviter que les modifications visuelles indésirables ne vous parviennent, à vous, les utilisateurs finaux. Un bogue visuel s'est-il quand même glissé dans le décor ? Continuez à lire cet article pour savoir comment nous gérons ce problème.