Réessayer ne répare pas le test

Prenons l'exemple d'une version illustrative : un test du paiement échoue, s'exécute à nouveau et réussit. Le tableau de bord est vert. Personne n'enquête. La prochaine version répète le modèle. Vous avez réduit le nombre de tableaux de bord rouges sans savoir si le paiement est fiable.

Playwright distingue trois résultats dans son guide des tentatives : réussi à la première tentative, irrégulier après une tentative ratée suivie d'un succès, et échec après les tentatives disponibles. Ce sont des éléments de preuve différents. Une suite générée doit préserver la distinction plutôt que d'aplatir chaque éventuelle réussite. L'artefact pratique de cet article est un registre de nouvelles tentatives qui survit à la couleur finale du tableau de bord.

Ce qu'une nouvelle tentative change réellement

Une nouvelle tentative donne au même test une autre chance d'être exécuté. Il ne corrige pas une assertion faible, ne répare pas un sélecteur ou ne sépare pas deux comptes qui écrasent les paramètres de chacun. Le Playwright rejette un processus de travail ayant échoué et en démarre un autre. Ses exemples documentés montrent que le hook beforeAll s'exécute à nouveau dans le nouveau travailleur. La configuration et le nettoyage font donc partie du calcul des coûts, et pas seulement les secondes passées à l'intérieur du corps d'essai.

Un nouveau navigateur n'est pas nécessairement une nouvelle base de données. Si la première tentative a créé une commande avant d'échouer, la tentative suivante peut rencontrer cette commande. Examinez les tests générés pour détecter les effets secondaires externes et déterminez si le nettoyage peut être répété en toute sécurité. Réessayer un achat contre production n'est pas une expérience acceptable ; utilisez des données intermédiaires et un compte de test limité.

Le grand livre à conserver à côté de CI

Pour chaque test, enregistrez son identifiant stable, le résultat de la première tentative, le résultat final, le nombre de tentatives, le lien de preuve, la cause suspectée, le propriétaire et la date de la prochaine révision. Conservez l'échec de la première tentative même si la dernière tentative réussit. Une équipe sans ingénieur QA dédié peut attribuer la propriété au développeur propriétaire du flux, plutôt que de laisser l'automatisation créer une file d'attente sans propriétaire.

Le grand livre constitue également une surface de révision utile pour les tests rédigés par les agents. Demandez à l'agent de rédiger un scénario, puis demandez à un humain de vérifier sa configuration, son assertion et son nettoyage. Une stratégie de nouvelle tentative est un paramètre d'exécution et ne remplace pas cette révision. La page publique d'AnyTest décrit l'exploration basée sur les URL et un examen humain de la suite ; il n'établit pas comment votre budget de nouvelle tentative CI particulier doit être choisi.

Chiffrer le travail répété

Utilisez un calcul illustratif avec des hypothèses explicites. Supposons que dix tests nécessitent chacun une tentative supplémentaire qui prend vingt secondes et que le redémarrage de l'installation ajoute cinq secondes par tentative. Cela représente dix fois vingt-cinq secondes, soit 250 secondes de travail d'exécution supplémentaire. Il ne s'agit pas nécessairement d'un délai d'horloge de 250 secondes, car les travailleurs parallèles peuvent se chevaucher. Enregistrez à la fois le travail des coureurs et le temps de pipeline écoulé si la distinction est importante pour votre facture ou votre fenêtre de sortie.

Ajoutez ensuite le temps que quelqu'un passe à lire des rapports flous. Si un agent économise une heure de création mais laisse une heure d'enquête récurrente, le numéro de création à lui seul ne décrit pas une économie. Pour une équipe d'assurance qualité existante, l'objectif est de réduire le travail répétitif et de consacrer plus de temps à l'analyse des risques. Pour une petite équipe sans assurance qualité, l'objectif est une couverture utile qu'un développeur peut réellement maintenir.

Une règle de publication que vous pouvez expliquer

Commencez par un petit paramètre de nouvelle tentative limitée et une catégorie floconneuse visible. Augmentez les échecs répétés de première tentative au lieu d'augmenter silencieusement la limite. Le bon seuil dépend du produit et du risque de rejet ; il n'existe pas de décompte universel qui rende acceptable un paiement irrégulier. Joignez un propriétaire de réparation et des preuves avant d'accepter une exception.

La question posée est simple : la deuxième tentative a-t-elle produit de nouvelles preuves, ou simplement une couleur que nous préférions ? Conservez la tentative échouée jusqu'à ce que quelqu'un puisse répondre.