Ce qui fait baisser le ratio des tests automatisés d'UI
Les sélecteurs
Une refonte qui ne change rien au fonctionnel fait passer la suite au rouge.
C'est là que part réellement l'essentiel du temps de maintenance.
L'attente
Les délais fixes sont lents et restent instables. Une attente correcte suppose de savoir ce que l'on attend.
C'est de là que vient la majeure partie de l'instabilité.
La 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.
Les sélecteurs et l'attente produisent des échecs qui ne sont pas des bugs. Chacun d'eux entame un peu la disposition de l'équipe à examiner le prochain build rouge.
Le moment où une suite meurt
On l'identifie généralement après coup : la semaine où quelqu'un a dit « il suffit de le relancer » et avait raison. À partir de là, relancer devient le premier réflexe face à n'importe quel échec, et une vraie régression est relancée jusqu'à ce qu'elle passe par chance ou finisse en quarantaine.
Personne ne décide de cesser de faire confiance à la suite. La confiance s'érode.
Protéger le ratio
Corrigez les tests instables avant d'en ajouter de nouveaux. Impopulaire, et pourtant juste. Un nouveau test ajouté à une suite que tout le monde ignore n'a aucune valeur.
Mettez en quarantaine de façon visible, pas en douce. Un test désactivé doit être visible et avoir un responsable, faute de quoi la liste des tests ignorés devient l'endroit où les tests vont mourir.
Considérez une relance comme un constat. Si un test a eu besoin d'être relancé, c'est que quelque chose ne va pas dans le test ou dans l'environnement. Consignez-le au lieu de passer à autre chose.
La part structurelle
La discipline règle les sélecteurs et les attentes. Elle ne règle pas le troisième coût : la couverture est limitée par ce qu'une personne peut écrire, et le produit grandit plus vite que cela, surtout quand une grande partie du code provient d'un agent de codage.
Des étapes exprimées comme des intentions plutôt que comme des chemins dans le DOM éliminent d'emblée une grande partie des échecs de sélecteurs, qui constituent le premier facteur de ce ratio.
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.
Redresser un ratio dégradé
Si la suite en est déjà au point où l'on relance au lieu d'enquêter, imposer de la discipline à partir de maintenant ne corrige rien, car le bruit existant continue d'entretenir l'habitude. La récupération passe par une remise à zéro délibérée.
Prenez les cinquante derniers échecs et classez chacun d'eux : réel, sélecteur, timing ou environnement. Cette heure de travail vous dira lequel des trois coûts vous avez réellement, et il est en général concentré plutôt que réparti. Corrigez cette seule catégorie sur l'ensemble de la suite, au lieu de corriger les tests au fur et à mesure de leurs échecs.
Mettez ensuite en quarantaine tout ce qui échoue encore, avec un responsable et une date, et laissez le reste de la suite au vert. Une petite suite verte à laquelle on fait confiance vaut mieux qu'une grande suite rouge que l'on a appris à ignorer, et c'est le seul état à partir duquel le ratio peut s'améliorer.
Exécutez-la là où les échecs coûtent le moins cher
À chaque pull request, pour qu'un échec désigne un seul changement plutôt qu'une semaine entière.
La GitHub App est un webhook que vous configurez dans le tableau de bord TestSprite. Elle écoute l'événement de déploiement que votre pipeline produit déjà, si bien que rien ne change dans votre dépôt.
GitHub Actions place l'étape à l'intérieur de votre propre workflow, configurée depuis le terminal.
Comment TestSprite protège le ratio
Directement, en supprimant la principale source de faux échecs. Les étapes sont des intentions plutôt que des localisateurs : les changements cosmétiques, qui provoquent l'essentiel des ruptures de sélecteurs, ne déclenchent donc pas de builds rouges. L'attente est prise en charge au lieu d'être un réglage à faire test par test, ce qui élimine la majeure partie du reste.
La couverture est générée à partir de votre produit et affinée en langage naturel : agrandir la suite n'implique donc pas d'augmenter la maintenance dans les mêmes proportions, ce qui est d'ordinaire ce qui oblige à arbitrer entre couverture et confiance.
Le résultat est une suite où un échec surprend. C'est dans cet état que l'on enquête au lieu de relancer, et c'est le seul état où la couverture peut continuer de croître sans que l'ensemble ne devienne peu à peu purement décoratif.
À quel taux de réussite faut-il s'attendre ?
Assez élevé pour qu'un build rouge soit surprenant. Si les échecs sont routiniers, la suite rend compte d'elle-même plutôt que du produit.
Comment corriger les tests instables ?
Déterminez s'il s'agit d'un sélecteur ou d'une attente. Les sélecteurs ont besoin de points d'ancrage stables, les attentes doivent attendre un état. Il existe une troisième catégorie : un environnement réellement instable, qu'aucune modification des tests ne corrige.
Vaut-il la peine de supprimer les anciens tests ?
Oui. Un test auquel personne ne fait confiance et que personne n'entretient est un coût sans bénéfice. Mieux vaut le supprimer que le désactiver.
La suite doit-elle bloquer les merges ?
Une fois le ratio sain, oui. Avant cela, bloquer les merges sur une suite peu fiable apprend surtout à la contourner.
Comment mesurer cela ?
Suivez la part des échecs qui s'avèrent réels. Si personne ne connaît ce chiffre, c'est déjà en soi le constat.
La couverture n'est pas le chiffre qui compte.
Les tests automatisés d'UI vivent ou meurent selon la proportion de builds rouges qui correspondent à de vrais bugs. Corrigez les tests instables avant d'en ajouter de nouveaux, considérez une relance comme un constat, et utilisez des étapes fondées sur l'intention pour éliminer les échecs de sélecteurs qui érodent la confiance.