Outils de test UI, vérification n° 1 : que se passe-t-il lors d'une refonte
C'est le coût récurrent de toute suite de tests navigateur, et la réponse varie énormément. Un outil dont les étapes sont des chemins dans le DOM passera au rouge à la moindre modification purement cosmétique. Un outil dont les étapes expriment une intention, le plus souvent, non.
Demandez à chaque éditeur de vous le démontrer concrètement plutôt que de vous le décrire.
Vérification n° 2 : qui écrit le deux centième test
Les dix premiers sont écrits pendant l'évaluation, par quelqu'un de motivé. Six mois plus tard, avec quarante nouveaux écrans et le porteur initial du projet parti ailleurs, la réponse honnête est souvent : personne. La plupart des suites abandonnées l'ont été à ce stade, et non pour une raison technique.
Vérification n° 3 : à quoi ressemble un échec pour celui qui doit le corriger
Une capture d'écran et une stack trace supposent qu'un humain les interprétera. De plus en plus souvent, celui qui corrige est un agent de codage, et il en est incapable. Un échec qui indique ce qui a été tenté, ce qu'a fait l'application et où les deux ont divergé est directement exploitable par l'un comme par l'autre.
Vérification n° 4 : une exécution qui n'a atteint aucune assertion est-elle signalée comme réussie
Testez-le délibérément pendant un essai, car la réponse est parfois oui, et cela invalide tout le reste. Une suite qui affiche du vert pour des exécutions expirées avant la moindre assertion est pire que pas de suite du tout, parce qu'elle produit de la confiance au lieu de l'information.
L'exercice qui vaut la peine d'être mené
Cassez quelque chose de réel. Un enregistrement qui ne persiste plus, un filtre qui renvoie silencieusement tous les résultats. Puis observez chaque candidat. Échoue-t-il, l'échec nomme-t-il la divergence réelle, celui qui devra corriger pourrait-il partir de cette sortie. Une demi-journée, et vous en apprendrez plus qu'en un mois de comparatifs.
Ce qu'il faut demander précisément au sujet des échecs
Chaque éditeur vous montrera une exécution qui passe. Les cinq minutes utiles d'une démo consistent à demander à en voir une qui échoue, et il y a trois choses à y chercher.
La sortie indique-t-elle ce qui était attendu, ou seulement ce qui s'est passé. Un rapport qui affiche la capture d'une page cassée sans préciser ce qui aurait dû s'y trouver vous laisse l'interprétation à votre charge.
Pouvez-vous dire à quel endroit du parcours l'échec s'est produit sans regarder une vidéo. La vidéo est un bon complément et un mauvais support principal, car parcourir un enregistrement de deux minutes pour retrouver le moment exact est précisément le travail que vous cherchiez à éviter.
Et un agent pourrait-il s'en servir pour agir. De plus en plus, ce qui corrige le bug n'est pas une personne, et cela change ce qu'est un bon rapport d'échec plus que tout le reste au cours des dix dernières années.
Les coûts qu'ils impliquent tous
Sélecteurs
Une refonte qui ne change rien au fonctionnement fait passer la suite au rouge.
Là où part réellement l'essentiel du temps de maintenance.
Attentes
Les délais fixes sont lents et restent instables. Des attentes correctes supposent de savoir quoi attendre.
L'origine de la plupart des instabilités.
Couverture écrite à la main
Vous couvrez ce que quelqu'un a écrit, c'est-à-dire les parcours intéressants plutôt que ceux qui cassent.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La même configuration est disponible dans le tableau de bord TestSprite si vous préférez ne rien installer en local. Le reste des commandes CLI se trouve dans le dépôt CLI.
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 lorsque votre build signale que la nouvelle version est en ligne. Si vous préférez que le contrôle soit visible dans le dépôt, une étape GitHub Actions s'en charge.
Comment TestSprite répond aux quatre vérifications
Lors d'une refonte, des étapes exprimées sous forme d'intentions survivent aux changements cosmétiques : la suite ne passe pas au rouge parce qu'un bouton a bougé. Le deux centième test est généré plutôt qu'écrit à la main, à partir de votre produit, puis affiné en langage courant. Un échec indique ce qui a été tenté, ce qu'a fait l'application et où les deux ont divergé, ce qui est exploitable aussi bien par un agent de codage que par une personne. Et une exécution qui n'atteint jamais ses assertions n'est pas signalée comme réussie.
Ce quatrième point mérite que vous le testiez vous-même pendant tout essai, y compris ici. Cassez un enregistrement pour qu'il ne persiste plus et vérifiez que le contrôle passe au rouge.
Vous obtenez une couverture qui suit le rythme d'une équipe qui livre plus vite qu'elle n'écrit de tests, et un signal d'échec que les gens continuent de lire parce qu'il est la plupart du temps réel.
La prise en charge des navigateurs compte-t-elle ?
Regardez d'abord vos statistiques d'audience. Beaucoup d'équipes paient pour couvrir des navigateurs que presque aucun de leurs utilisateurs n'utilise.
Open source ou commercial ?
Le coût est rarement dans la licence. Il est dans l'écriture et la maintenance, et celles-ci sont comparables dans les deux cas.
Pourrons-nous migrer plus tard ?
Partez du principe que les tests ne seront pas portables. Choisissez en fonction de là où vous pensez être dans un an, plutôt qu'en prévoyant de changer.
Combien de temps doit durer un essai ?
Assez longtemps pour englober une refonte ou une vraie régression. Sans l'une ou l'autre, vous n'avez évalué que la démo.
Et s'il nous en faut plusieurs ?
C'est courant et ce n'est pas un problème. Un framework de code pour les parcours choisis, complété par une couverture générée pour l'étendue, est une organisation normale.
Quatre vérifications valent mieux que n'importe quel tableau comparatif de fonctionnalités.
Quand vous comparez des outils de test UI, vérifiez ce qui se passe lors d'une refonte, qui écrit le deux centième test, à quoi ressemble un échec pour celui qui doit le corriger, et si une exécution sans assertion est signalée comme réussie. Puis cassez quelque chose volontairement.