Ce qui exige vraiment des tests UI
Le parcours fonctionne de bout en bout. Un utilisateur peut passer de l'intention au résultat. Aucune couche située sous l'interface ne peut répondre à cette question.
L'état d'une étape à l'autre. Ce qui est défini sur un écran est bien pris en compte sur le suivant. C'est là que se concentrent les vrais défauts.
Ce qu'on annonce à l'utilisateur correspond à ce qui s'est réellement passé. Un message de succès sans enregistrement sauvegardé est le mensonge le plus courant d'une application.
Ce qui n'a pas sa place dans un test UI
Les règles de validation
Passer chaque combinaison de saisie invalide par le navigateur est lent et fragile.
Vérifiez-en une dans l'UI, le reste au niveau de l'API.
Les calculs
Un test unitaire y répond en quelques millisecondes, avec un meilleur message d'échec.
La préparation des données
Cliquer à travers cinq écrans pour créer un jeu de données est lent et casse pour des raisons sans rapport avec ce que vous testez.
Dimensionner la suite
Deux règles utiles. Couvrez les parcours selon la discrétion avec laquelle ils échoueraient plutôt que selon leur importance, car les parcours importants sont surveillés, les discrets non. Et arrêtez d'en ajouter quand le coût de maintenance commence à ronger le temps que vous gagniez, ce qui arrive plus tôt que la plupart des équipes ne l'imaginent.
Les trois habitudes
Des ancrages stables, pas des chemins CSS. Élimine l'essentiel des casses liées aux refontes.
Attendez un état, pas un délai. Élimine l'essentiel de l'instabilité.
Vérifiez ce qu'un rechargement de page confirmerait. Élimine la fausse confiance que donne un message de succès.
Descendre un test d'une couche, en pratique
Le conseil de déplacer les vérifications sous l'interface est facile à approuver mais vague à appliquer ; voici donc ce que cela donne sur un exemple concret.
Vous avez un test navigateur qui remplit un formulaire d'inscription avec quatorze saisies invalides différentes et vérifie le message d'erreur à chaque fois. Il prend quatre minutes, casse dès que la mise en page du formulaire change, et ne vous apprend presque rien sur le navigateur.
Remplacez-le par un seul test navigateur qui soumet une saisie invalide et confirme qu'une erreur est bien affichée à l'utilisateur, plus treize tests API qui vérifient directement les règles de validation. Le test navigateur répond désormais à une question de navigateur, les règles sont couvertes plus vite et plus précisément, et une modification de validation n'oblige plus à toucher quoi que ce soit qui s'affiche.
Ce que la discipline ne peut pas corriger
Les sélecteurs
Une refonte qui ne change rien au fonctionnel fait passer la suite au rouge.
Là où part réellement l'essentiel du temps de maintenance.
L'attente
Les délais fixes sont lents et restent instables. Des attentes correctes supposent de savoir quoi attendre.
L'essentiel de l'instabilité vient de là.
La couverture rédigée à la main
Vous couvrez ce que quelqu'un a écrit, c'est-à-dire les parcours intéressants plutôt que ceux qui cassent.
La troisième est structurelle. Une couverture limitée par le temps de rédaction prendra du retard sur un produit dont le code provient de plus en plus d'un agent. Les étapes fondées sur l'intention et la couverture générée répondent à ce point.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Le tableau de bord couvre le même terrain pour qui ne veut pas d'installation locale, et l'ensemble des commandes se trouve dans le dépôt CLI.
Connectez le dépôt depuis le tableau de bord et les exécutions démarrent à partir du déploiement que vous produisez déjà, ou ajoutez plutôt une étape à votre propre workflow.
Ce que TestSprite couvre à chaque couche
Les parcours dans le navigateur, là où seul un navigateur peut répondre, et la couche API en dessous, dans le même projet. C'est ce qui rend le conseil « descendez d'une couche » applicable plutôt que théorique : les règles de validation passent dans des cas API qui s'exécutent en quelques secondes, et un seul cas navigateur vérifie que le formulaire y est bien relié.
Les deux sont générés à partir de votre produit et affinés en langage naturel, et les étapes navigateur sont des intentions plutôt que des sélecteurs : la suite survit donc aux refontes qui ne changent rien au fonctionnel.
Vous obtenez au final une suite navigateur assez réduite pour qu'on lui fasse confiance, couvrant les parcours qui comptent, avec les règles et les cas limites couverts plus vite une couche en dessous.
Combien de tests UI faut-il ?
Assez pour couvrir les parcours qu'il serait embarrassant de casser, choisis selon la discrétion avec laquelle ils échoueraient. Descendez tout le reste d'une couche.
Faut-il tester chaque écran ?
Non. Testez des parcours, pas des écrans. Un écran que ne traverse aucun parcours justifie rarement un test navigateur.
Et l'accessibilité ?
Elle mérite d'être automatisée pour les vérifications mécaniques, et le reste demande une relecture humaine. C'est un sujet à part, avec son propre outillage.
La couverture multinavigateur est-elle nécessaire ?
Cela dépend de vos statistiques d'audience. Beaucoup d'équipes exécutent une suite complète sur un navigateur et une suite de smoke tests sur les autres, ce qui est généralement le bon compromis.
Quand faut-il exécuter les tests UI ?
À chaque pull request. Moins souvent, un échec désigne un lot de modifications plutôt qu'une seule.
Testez les parcours dans l'UI, tout le reste en dessous.
Les tests UI doivent couvrir les parcours de bout en bout, l'état d'une étape à l'autre, et la correspondance entre ce qu'on annonce à l'utilisateur et ce qui s'est réellement passé. La validation, les calculs et la préparation des données relèvent de la couche inférieure, où ils sont plus rapides et plus faciles à diagnostiquer.