Maintenir la qualité de bout en bout avec des tests visuels

Les tests sont une partie essentielle du flux de travail de tout développeur. Cela nous aide à nous assurer que notre projet va maintenir un haut niveau de qualité, ainsi qu'à empêcher tout bug gênant de se répandre dans la nature.

Mais souvent, les tests automatisés peuvent être pénibles à gérer. Entre une quantité infinie de code pour vous assurer que vous fournissez une couverture complète et la nature fragile des tests frontaux - où un simple changement de sélecteur peut complètement rompre un flux de travail de bout en bout - cela peut parfois sembler une montée bataille.

En ajoutant des tests visuels automatisés , nous pouvons éliminer ces tests aléatoires, en améliorant nos pipelines de test fournissant cette couverture (et plus) en tirant parti de comparaisons d'images intelligentes à l'aide de captures d'écran de notre site Web ou de notre application.

Avant de plonger dans les tests visuels, prenons une minute pour nous rafraîchir sur les différents types de tests automatisés et comment ils s'articulent. Nous parlerons ensuite de ce qu'est exactement le test visuel et comment il peut vous fournir un autre niveau de couverture de test pour votre projet.

Un aperçu rapide de certains des types de tests automatisés

Les tests automatisés sont une partie intéressante du cycle de développement. Certains clients ou parties prenantes sont en mesure de voir clairement la valeur qu'ils apportent, mais d'autres préféreraient que tout temps de développement soit consacré au développement de fonctionnalités pures.

Cela peut parfois être contre-intuitif, où l'objectif des tests automatisés est de protéger l'entreprise ou d'éviter à l'équipe d'avoir à passer du temps à corriger des bogues en premier lieu. Rédiger des tests automatisés solides peut éviter des pertes financières importantes ! C'est finalement un risque que certains sont plus disposés à prendre que d'autres.

Heureusement, cette valeur n'est pas toujours difficile à vendre, et lorsque nous avons le temps de nous concentrer sur des tests automatisés de qualité, nous avons une variété d'options pour aborder ces tests comme les tests unitaires, les tests d'intégration, de bout en bout tests et tests visuels (qui peuvent également fournir une couverture étendue pour les trois premiers).

Lorsqu'ils sont appliqués avec les points forts de chaque type de test, nous sommes en mesure de passer plus de temps à rédiger des tests qui peuvent réellement aider à protéger notre travail et à éviter la frustration de nos clients.

Voyons à quoi ressemblent certaines de ces stratégies de test dans la pratique.

Tests unitaires

Les tests unitaires se concentrent sur le test de zones plus petites et ciblées d'une application . Vous voulez tester qu'une fonction qui calcule le total d'une commande après les promotions fonctionne correctement ? Vous voudriez écrire un test unitaire.

 function myBusinessLogic(pricePerItem, quantity, discount) { const subtotal = pricePerItem * quantity; return subtotal - ( discount * subtotal ); } expect(myBusinessLogic(2, 4, .1)).toEqual(7.2);

La grande partie des tests unitaires est qu'ils sont peu coûteux à écrire et ne prennent pas beaucoup de temps à exécuter. C'est pourquoi vous verrez souvent les entreprises passer beaucoup de temps à créer une suite de tests unitaires pour capturer ces éléments granulaires d'une application.

Mais à cause de ces tests ciblés, les tests unitaires peuvent ne pas couvrir la façon dont ces différents éléments fonctionnent ensemble, c'est là que nous commençons à passer aux tests d'intégration.

Tests d'intégration

L'objectif des tests d'intégration est de prendre les plus petits éléments et composants d'une application et de tester comment ils fonctionnent ensemble . Un exemple courant pourrait être la manière dont une partie particulière d'une interface utilisateur répond aux interactions suivies de requêtes adressées à un serveur ou à une base de données.

 cy.get('.add-to-cart').click(); cy.url().should('contain', 'cart'); cy.get('.cart li').contains('My Item');

Il est tout à fait possible que votre petit composant d'interface utilisateur fonctionne comme prévu par lui-même. Vos événements synthétiques peuvent se déclencher correctement sur une instance onClick. Ce code enveloppant vos requêtes API peut fonctionner parfaitement avec certaines données simulées. Mais il peut y avoir des trous entre ces deux pièces travaillant ensemble que vos tests unitaires pourraient ne pas détecter.

Les tests d'intégration sont un moyen convaincant de tester votre application, mais vous pouvez aller plus loin en cherchant à tester "toutes les choses".

Test de bout en bout

Les tests de bout en bout capturent l'ensemble du parcours d'un utilisateur de bout en bout pour un flux de travail ciblé. Par exemple, si je construis un magasin de commerce électronique, le "chemin heureux" (ou le chemin attendu avec le moins de résistance) serait de trouver un produit, de l'ajouter à un panier et de payer pour ces articles. Si j'écris un test de bout en bout, je capturerais l'ensemble du processus, c'est-à-dire de la recherche d'un produit sur une page de liste de produits au paiement de cet article.

 cy.visit('/products'); cy.get('.product a[href="/product/1234"]').click() cy.url().should('contain', 'product/1234'); ... cy.get('.order-button').click(); cy.url().should('contain', 'receipt'); cy.get('.receipt li').contains('My Item');

La grande partie des tests de bout en bout est qu'il s'agit essentiellement d'un gros test d'intégration. Vous capturez de nombreux composants différents de l'application, notamment le fonctionnement de l'interface utilisateur, le fait que les API répondent correctement et que ces éléments fonctionnent ensemble.

Le problème est que les tests de bout en bout, et même les tests d'intégration, prennent plus de temps à écrire et leur exécution prend également beaucoup plus de temps. Alors, comment pouvons-nous tirer parti de toutes nos options de test et mettre en place une suite de tests qui fournira un moyen efficace de couvrir notre application ?

Tirer parti des différents types de tests

Il existe une variété d'états d'esprit qui décrivent généralement combien de tests de chaque type vous devriez passer du temps à écrire.

Mike Cohn a proposé le concept de « pyramide de test » dans son livre Réussir avec Agile .

Il soutient que vous devriez écrire plus de tests unitaires là où ils sont moins coûteux à écrire et plus rapides à exécuter. Bien que son diagramme original étiquette les différents tests un peu différemment, à mesure que vous vous penchez davantage sur les tests de type intégration, ils deviennent plus lents à exécuter et plus coûteux à écrire. Bien que ces tests soient précieux, vous ne voulez pas avoir autant d'intégrations ou de tests de bout en bout que vous le feriez avec des tests unitaires.

Avoir cet équilibre peut vous aider à vous concentrer sur la capture des parties critiques de l'application, telles que la logique métier avec les tests unitaires et la façon dont ils fonctionnent avec les tests d'intégration, mais Kent C. Dodds affirme que la technologie de test a atteint un point où il n'y a plus des compromis de coûts plus longs pour écrire des tests d'intégration, c'est là qu'intervient son concept de « trophée de test ».

Dans les environnements de développement modernes, nous avons à notre disposition de nombreux outils incroyables comme Cypress, Selenium et Playwright qui donnent chacun aux développeurs et aux ingénieurs QA la possibilité d'écrire des tests qui interagissent facilement avec des navigateurs comme Chrome et Firefox.

Avec Cypress, écrire un test qui clique sur un bouton peut sembler aussi simple que :

 cy.get('#my-button').click()

C'est sans doute aussi simple que de tester que le bouton fonctionne avec des événements synthétiques, sinon plus simple. La meilleure partie est que vous testez le fonctionnement réel de ce bouton dans un navigateur.

Quel que soit le diagramme auquel vous vous abonnez, l'objectif final est de peser les différentes options entre le coût et la vitesse pour déterminer la bonne solution pour votre application particulière. Il est important de ne pas simplement atteindre 100 % sur votre rapport de couverture, mais de vous assurer que l'expérience que vous offrez aux visiteurs fonctionne comme il se doit.

Mais quelle que soit la combinaison de tests que vous exécutez, ces tests programmatiques qui interagissent et testent uniquement le DOM (Document Object Model) manquent une grande pièce du puzzle : comment vos visiteurs voient visuellement cette application.

Ce que les types de tests traditionnels ne capturent pas

Lorsque vous exécutez vos tests unitaires, d'intégration et de bout en bout sur votre application, ils ont tous une chose en commun. Ils testent tous le code.

Ce que je veux dire par là, c'est qu'ils ne testent pas ce que le visiteur de votre application voit réellement.

Si vous exécutez une suite de tests d'intégration et, comme dans notre exemple précédent, testez que quelqu'un peut ajouter un produit à un panier et l'acheter, à chaque étape du processus, vous trouvez un élément dans le DOM via le code et confirmez que cela a fonctionné de la même manière.

Cela ne teste pas des choses comme si le texte de votre page est lisible ou non. Quelqu'un a-t-il ajouté un changement CSS qui a accidentellement fait flotter toutes les choses vers la gauche et les a renversées ?

Ces types de bugs sont appelés "bugs visuels", où ils peuvent réussir tous vos tests avec brio, mais quand quelqu'un le regarde réellement, ce n'est pas tout à fait correct ou pire, complètement inutilisable.

De manière réaliste, nous ne pouvons pas nous attendre à fournir une couverture complète à 100 % de chaque détail d'une interface utilisateur avec des tests traditionnels. Entre le nombre infini d'états d'application et le fait que nous ajoutons constamment de nouvelles fonctionnalités, cela ne s'adapte tout simplement pas.

C'est ce qui nous amène au titre de cette histoire : Visual Testing .

Qu'est-ce qu'un test visuel ?

Visual Testing capture la sortie visible (comme une capture d'écran) d'une application et la compare à la même application à un autre moment.

Cela se produit généralement en capturant d'abord une capture d'écran de référence ou une instance précédemment capturée de l'application avec les résultats attendus, et en comparant chaque nouveau test à cette référence.

Mais au fur et à mesure que votre projet se développe, les choses changent. Au fil du temps, cette ligne de base sera mise à jour avec votre application lorsque vous approuverez de nouvelles différences visuelles en tant que modifications acceptées.

Types de tests visuels

Une chose intéressante à propos des tests visuels est qu'il existe différentes façons de gérer cela.

Une approche pour tester visuellement consiste à utiliser des comparaisons pixel par pixel dans lesquelles le cadre de test signalera littéralement toute différence qu'il voit entre deux images. Bien que de telles comparaisons fournissent une entrée de gamme dans les tests visuels, elles ont tendance à être irrégulières et peuvent conduire à de nombreux faux positifs.

Comme vous pouvez l'imaginer, lorsque vous travaillez avec le Web, les choses ont tendance à être très légèrement différentes entre les chargements de page et les mises à jour du navigateur. Si le navigateur affiche la page de 1 pixel en raison d'un changement de rendu, de l'affichage de votre curseur de texte ou "juste parce que", vos déploiements peuvent être bloqués en raison de l'échec de ces tests.

Vos tests sont également sujets à des échecs lorsqu'ils traitent avec du contenu dynamique. Par exemple, si vous exécutez quotidiennement des tests visuels pixel par pixel sur la page d'accueil de ce site, Smashing Magazine , vous obtiendrez de nombreux tests ratés car ils produisent de plus en plus de contenu.

Une meilleure façon de gérer les tests visuels consiste à tirer parti d'une technologie telle que l'IA où chaque fois qu'un test est exécuté, le cadre de test examine intelligemment la capture d'écran par rapport à la ligne de base.

Il peut détecter que les deux captures sont différentes ou même détecter s'il s'agit d'un changement de contenu par opposition à un changement de mise en page. Il ne signalera pas ce test comme ayant échoué si quelque chose n'a pas réellement changé et vous pouvez même ajouter des règles pour ignorer les régions dynamiques d'une application qui pourraient changer en raison de ce contenu.

Où les tests visuels aident

Les tests visuels prospèrent en étant capables de capturer l'état actuel d'une application exactement comme votre client l'a vu. Cela le rend convaincant pour vraiment n'importe quelle application qui aura de vrais humains qui interagissent avec elle.

Comme il capture cet instantané, il fournit une couverture de nombreux éléments de cette application, et pas seulement d'un seul composant granulaire pour lequel vous avez écrit un test. Il finit par capturer le contexte autour de ce composant, conduisant à une couverture plus large.

Cela devient un excellent moyen de fournir une large couverture avec une faible surcharge . Pour en revenir à la pyramide des tests ou au trophée des tests, nous sommes en mesure de fournir une couverture complète en plus de tous nos autres tests.

Comment fonctionnent les tests visuels ?

L'essentiel est simple - comparer deux images l'une contre l'autre et rechercher la différence - mais c'est un peu plus complexe que cela.

Comparaisons d'images

Lors de la mise en œuvre des tests visuels, l'objectif sera de fournir une couverture pour les flux de travail critiques qui peuvent capturer la façon dont une personne réelle utilise l'application. Cela inclut souvent le tout premier écran que quelqu'un peut voir, mais ce n'est généralement pas le seul écran qu'il voit.

Tout comme pour la création d'une stratégie sur la façon d'exécuter des tests traditionnels, vous voulez vous assurer de rechercher de vraies interactions qui aboutissent à de vrais résultats dans l'interface utilisateur, comme l'ajout d'un article à un panier ou l'ajout d'un article préféré à votre liste de souhaits.

Dans cet esprit, vous voudrez capturer une capture d'écran à chaque étape du processus. Par exemple, si vous testiez une boutique en ligne, vous souhaiterez peut-être ajouter des étapes pour les éléments suivants :

• Liste des produits chargés sur une page ;
• Page produit après avoir sélectionné un seul produit ;
• Interface utilisateur du panier sur la page après avoir ajouté un produit à ce panier ;
• Page du panier après avoir navigué vers le panier ;
• Interface utilisateur de paiement et d'expédition une fois dans le flux de paiement ;
• Page de réception lors de l'achat réussi.

Cela capturera les résultats de toutes les interactions au fur et à mesure que quelqu'un parcourt votre boutique en ligne, où vous pourrez vérifier que non seulement cela fonctionne fonctionnellement du point de vue du code, mais que la personne peut réellement utiliser votre application sans bugs visuels interférant.

Bits techniques

Au fur et à mesure que vous progressez dans la planification des captures d'écran, vous aurez besoin d'un mécanisme pour automatiser ces tâches. Quelque chose qui peut interagir avec un navigateur basé sur un ensemble de tâches.

C'est là qu'interviennent les frameworks d'automatisation de navigateur populaires tels que Selenium, Cypress et Playwright, où ces frameworks de test tirent parti des API du navigateur pour exécuter vos commandes, trouver et cliquer sur des choses comme le ferait un humain, où vous diriez alors le cadre de test visuel quand capturer visuellement l'état de l'interface utilisateur.

Dans le cas de Cypress et Applitools, Cypress naviguait sur chaque page, où le SDK Applitools extrayait un instantané du DOM et envoyait cet instantané au cloud Applitools, où il générerait enfin des captures d'écran à des fins de comparaison.

À ce stade, selon la plate-forme de test visuel, vous obtiendrez un ensemble de résultats sous la forme de différences mises en évidence ou d'une jolie coche verte si tout semble bon.

Intégration avec les frameworks de test existants

Comme l'intégration Cypress et Applitools ci-dessus, l'intégration a généralement une faible friction. De nombreuses plates-formes de test visuel disponibles peuvent s'intégrer directement dans les frameworks de test existants, cela dépend principalement des SDK dont elles disposent.

 cy.visit('/product/1234'); cy.eyesOpen({ appName: 'Online Store', testName: 'Product Page' }); cy.eyesCheckWindow(); cy.eyesClose();

Cela signifie que vous n'avez généralement pas besoin de réécrire complètement votre suite de tests pour renforcer vos tests et obtenir une couverture visuelle ; vous pouvez ajouter ces points de contrôle aux tests que vous avez déjà.

Automatisation des tests

Heureusement, l'automatisation des tâches de développement et de test a rapidement mûri, offrant de nombreuses options intéressantes pour automatiser nos tests.

Les solutions CI/CD traditionnelles telles que Jenkins ou Travis CI vous permettent d' exécuter vos tests sur leurs environnements parallèlement au reste du pipeline d'intégration et de déploiement. Des outils comme GitHub Actions sont relativement nouveaux dans l'espace d'automatisation, où ils fournissent un mécanisme similaire aux environnements CI/CD traditionnels, mais directement à l'intérieur de votre référentiel GitHub existant. Cela en fait une victoire facile lorsque vous essayez d'exécuter automatiquement vos tests et autres tâches de code, où vous n'avez pas besoin d'un système entièrement nouveau, mais utilisez plutôt vos outils existants.

 name: Node.js CI on: [push, pull_request] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - run: npm ci - run: npm test

Mais quel que soit l'environnement que vous utilisez, vous êtes finalement soumis aux exigences du cadre de test. Cypress fonctionne de manière assez transparente partout où vous pouvez installer Node.js, ce qui est assez courant de nos jours, tant que vous avez accès à un navigateur sans tête comme Electron ou Chrome. D'autres peuvent nécessiter un petit environnement supplémentaire, mais à ce stade, vous pouvez généralement échafauder cet environnement comme vous le souhaitez, en créant les conditions dont vous avez besoin pour exécuter vos tests.

Quels sont les avantages des tests visuels ?

Les tests visuels vont offrir une grande variété d'avantages comme certains de ceux dont nous avons déjà parlé, mais ils aident vraiment toutes les parties prenantes, y compris les cadres, les chefs de produit, les développeurs, les concepteurs et vraiment tous les autres membres de l'équipe.

Par exemple, pour un PDG ou un chef de produit, vous gagnez en confiance que votre couverture de test capture réellement l'utilisation dans le monde réel . Pour l'équipe de développement, vous gagnez la même confiance que chaque fois que vous apportez des modifications, vous obtiendrez un retour immédiat, éliminant ainsi le facteur de peur impliqué lorsque vous essayez d'agir rapidement. Mais il y a aussi beaucoup d'avantages pratiques.

Moins de code à maintenir

Lors de l'intégration avec une plate-forme de test visuel, la majorité de votre code va tourner autour de deux choses : les interactions et les captures d'écran.

Les interactions consistent essentiellement à naviguer dans une application, à trouver la page ou le flux d'utilisateurs que vous souhaitez capturer. Quelle que soit la manière dont vous testez, vous devrez probablement le conserver sous une forme ou une autre.

Les captures d'écran, d'autre part, couvriront toutes les assertions que vous écririez normalement dans un test. En comparant chaque capture d'écran à une ligne de base, vous vous assurez automatiquement que chaque composant de votre projet fonctionne exactement comme prévu.

Les tests sont moins fragiles

Et en utilisant ces captures d'écran comme mécanisme d'assertion, vos tests seront moins floconneux et moins fragiles.

Si vous écrivez une assertion sur une partie particulière du DOM, comme l'utilisation d'un ID ou d'un sélecteur généré automatiquement, vous risquez un test de rupture avec toute modification apportée à ce composant.

Avec un identifiant, quelqu'un peut simplement le supprimer ou le modifier accidentellement. Peut-être que vous pensiez que c'était uniquement à des fins fonctionnelles et que vous l'aviez mis à jour lors de la refonte des choses, ce qui a fini par casser le test (ce qui m'est arrivé !).

Ou si vous utilisez des sélecteurs généraux, qu'ils soient générés automatiquement ou non, ils ont tendance à être très spécifiques car vous testez des parties très spécifiques de l'application . Si vous finissez par imbriquer du code HTML ou déplacer un peu des éléments dans le code, même si vous n'avez pas modifié son apparence visuelle, cela pourrait finir par casser ce test.

Tester ce que les gens utilisent réellement

En parlant de tester son apparence visuelle, lors d'un test visuel, vous testez ce que vos visiteurs ou clients voient réellement.

L'utilisation d'un code HTML sémantique approprié ne rend pas automatiquement votre projet utilisable. Un petit changement CSS (comme z-index) peut complètement changer la convivialité et l'apparence de quelque chose.

En capturant une capture d'écran et en comparant l'état réel de l'application à travers les interactions du flux d'un utilisateur, vous êtes en mesure de vous assurer que votre application fonctionne à la fois fonctionnellement et qu'elle est utilisable par plus que de simples robots d'automatisation.

Lecture recommandée : Gérer CSS Z-Index dans les grands projets

Tester des choses que vous n'aviez pas pensé à tester

Vous obtenez également une couverture de différentes parties de votre application que vous n'aviez même pas pensé à tester.

Considérez la liste des tests que vous avez dans votre suite, ce sont ceux que vous pensiez écrire ou avez écrits parce que vous avez déjà rencontré un bogue. Qu'en est-il du reste de l'application ?

Cette capture d'écran va capturer plus de détails et de contexte que vos autres tests n'auraient peut-être pas inclus.

Qu'est-ce que les tests visuels ne couvrent pas ?

Mais les tests visuels ne sont pas destinés à être une solution ultime pour remplacer toute votre suite de tests. Comme les autres types de tests, il devrait coexister, combler les lacunes des autres et finalement fournir une couverture plus significative.

Tester la logique métier basée sur les données

Au fur et à mesure que vous effectuez des tests visuels, vous pourrez peut-être capturer certains aspects de votre logique métier, comme vous assurer que lorsque quelqu'un ajoute un article au panier, que les calculs sont vérifiés, mais votre boutique en ligne a probablement une plus grande variété que ce seul produit.

Il est toujours important de capturer cette logique métier complexe avec les tests unitaires, en vous assurant de capturer différents cas d'utilisation, comme l'impact de diverses remises sur ce total.

Tests API complets

Lorsqu'il s'agit d'API, vous pouvez considérer un test visuel comme un test d'intégration. Nous sommes en mesure de tester que lors de l'interaction avec le navigateur, notre logique de requête fonctionne comme prévu. Mais cela ne fournit pas un aperçu complet du fonctionnement de cette API.

Semblable à la logique métier, votre API doit toujours être soutenue par une suite de tests qui garantiront qu'elle fonctionne comme prévu, tels que des tests unitaires ou des vérifications de l'état.

Premiers pas avec les tests visuels

En tant qu'autre outil de notre ceinture, les tests visuels peuvent vraiment aider à fournir un autre niveau de couverture qui nous aide à maintenir un haut niveau de qualité pour nos applications, mais par où commencer ?

S'adapter au cycle de vie du développement

Parce que les tests visuels aident à atteindre les objectifs de toutes les parties prenantes, cela peut vraiment s'intégrer à n'importe quelle partie du cycle de vie du développement.

Par exemple, traditionnellement, les tests ne sont utilisés que pour valider que le code fonctionne comme prévu, mais nous pouvons également utiliser des tests visuels pour le transfert de conception et la collaboration UX . Les concepteurs de l'équipe peuvent intégrer leurs maquettes comme référence et les utiliser facilement pour comparer l'expérience réelle.

Mais du point de vue du code, les tests visuels peuvent prospérer dans des environnements automatisés, tels que l'exécution de vérifications sur les demandes d'extraction, sur les environnements de mise en scène avant le déploiement et la vérification de la qualité de la production après le déploiement.

Vous pouvez même exécuter vos tests visuels sur un cron, en remplaçant vos événements synthétiques de vérification de l'état, qui sont généralement floconneux et ne vous disent jamais vraiment dans quel état se trouve votre application.

Heureusement, il existe de nombreuses options pour le service que vous utilisez, mais également pour les points d'intégration permettant d'utiliser ces services.

Solutions disponibles pour les tests visuels

La détermination de la solution à utiliser repose sur le choix de la bibliothèque ou du service que vous utiliserez pour exécuter les tests. Comme nous l'avons vu précédemment, le plus grand différenciateur sera le type de test visuel fourni par ces services.

De nombreuses plates-formes utilisent des tests visuels pixel par pixel pour effectuer des vérifications. Cela inclut des outils comme Percy et Chromatic qui signaleront les changements entre deux captures d'écran.

Ensuite, vous avez des tests visuels alimentés par l'IA, où Applitools est vraiment le seul service qui offre actuellement cette capacité. Au lieu de simplement vérifier les images pixel par pixel, Applitools compare intelligemment les images en évitant les tests aléatoires ou les faux positifs , ce qui permet une détection significative des changements.

Quelle que soit la solution, vous devrez finalement l'intégrer à votre environnement de développement, que vous partiez de zéro ou que vous l'ajoutiez à un framework de test existant.

Intégration des tests visuels

Lors de l'intégration de la plate-forme de test visuel de votre choix, vous avez la possibilité de partir de zéro ou de suivre la voie plus simple de l'intégration dans votre cadre de test existant. Des outils comme Applitools facilitent cette tâche, où la grande variété de SDK pris en charge facilite l'intégration dans les flux de travail existants.

Un bon exemple de ceci est si vous êtes déjà configuré et utilisé avec Cypress :

 it('should log into the application', () => { cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.get('h1').contains('Dashboard'); });

Si vous effectuez déjà des tests programmatiques, vous pouvez simplement superposer des tests visuels pour fournir une autre couche de couverture.

 it('should log into the application', () => { cy.eyesOpen({ appName: 'My App', testName: 'Login' }); cy.get('#username').type('colbyfayock'); cy.get('#password').type('Password1234'); cy.get('#log-in').click(); cy.eyesCheckWindow(); cy.eyesClose(); });

Et certains SDK le rendent encore plus facile, où si vous utilisez déjà une bibliothèque Storybook, tout ce que vous avez à faire est d'installer le package avec npm et d'exécuter une simple commande, vous avez alors une couverture complète de tous vos composants.

 npm install @applitools/eyes-storybook --save-dev npx eyes-storybook

En fin de compte, la plus grande question est de savoir quel framework de test vous voudrez utiliser et si le service que vous souhaitez utiliser prend en charge ce framework.

Utilisations créatives des tests visuels

En plus d'obtenir un autre niveau de couverture de test pour votre application, il existe de nombreuses autres façons de tirer parti des tests visuels.

• Surveillance de la disponibilité
  Exécutez régulièrement un test visuel significatif au lieu d'une surveillance typique de la disponibilité avec des événements synthétiques fragiles.
• Conception/Collaboration UX
  Du transfert aux problèmes d'utilisabilité, utilisez les tests visuels pour donner à toute l'équipe un moyen de collaborer.
• Test d'accessibilité
  Capturez les problèmes clés qui peuvent limiter l'accessibilité de votre application.
• Instantanés historiques
  L'exécution périodique d'un test visuel peut vous aider à capturer des instantanés, vous donnant facilement un moyen de référencer un état plus ancien du projet.
• Test de localisation
  Grâce aux tests visuels basés sur l'IA capables de détecter les changements de contenu, vous avez la possibilité de vous assurer que tout se présente et fonctionne comme prévu, quelle que soit la langue. Bonus : vous pouvez réduire les frais généraux lorsque vous essayez de comparer différentes versions d'une langue donnée.

En ajoutant l'élément visuel à vos tests, vous obtenez plus d'options pour ajouter des moyens significatifs de maintenir un haut niveau de qualité pour votre application.