Les tests sont précieux. À tout le moins, ils enregistrent que quelqu'un considérait qu'ils devraient passer du temps à les écrire, donc ils ont vraisemblablement eu une certaine valeur pour quelqu'un une fois. Avec de la chance, ils contiendront un enregistrement complet de toutes les fonctionnalités et bogues sur lesquels l'équipe a jamais travaillé - bien qu'ils puissent également être un moyen d'atteindre un certain nombre arbitraire de couverture de test sans être soigneusement réfléchi. Jusqu'à ce que vous les regardiez, vous ne saurez pas quel est le cas ici.
Si la plupart de vos tests réussissent la plupart du temps, alors mordez la balle et investissez du temps à déterminer ce que les quelques tests qui échouent tentaient de faire, et à les corriger ou à les améliorer pour que le travail soit plus facile la prochaine fois. Dans ce cas, passez à la section Déterminer l'intention de chaque test pour obtenir des conseils sur la procédure à suivre avec un petit nombre de tests ayant échoué.
D'un autre côté, vous pouvez être confronté à une version rouge maintenant, et à des centaines voire des milliers de tests qui n'ont pas réussi depuis un certain temps, et Jenkins n'a pas été vert depuis longtemps. À ce stade, l'état de la génération Jenkins est devenu inutile et un indicateur clé de problèmes avec votre enregistrement ne fonctionne plus. Vous devez résoudre ce problème, mais vous ne pouvez pas vous permettre d'arrêter tout progrès vers l'avant pendant que vous nettoyez le gâchis dans votre salon.
Afin de garder votre santé mentale tout en effectuant l'archéologie requise pour déterminer quelle valeur peut être récupérée à partir des tests qui ont échoué, je recommanderais les étapes suivantes:
Désactivez temporairement les tests ayant échoué.
Il y a plusieurs façons de le faire, en fonction de votre environnement, que vous ne décrivez pas clairement, donc je ne peux vraiment pas en recommander un en particulier.
Certains cadres prennent en charge la notion de défaillances attendues. Si le vôtre le fait, c'est parfait, car vous verrez un compte à rebours du nombre de tests restant dans cette catégorie, et vous serez même informé si certains d'entre eux commencent à passer de manière inattendue.
Certains frameworks prennent en charge les groupes de tests et vous permettent d'indiquer à Hudson uniquement d'exécuter certains des tests ou d'ignorer un groupe de tests. Cela signifie que vous pouvez occasionnellement exécuter le groupe de tests manuellement pour voir si certains réussissent.
Certains frameworks vous permettent d'annoter ou de marquer autrement des tests uniques à ignorer. Dans ce cas, il est plus difficile de les gérer en groupe, mais cela les empêche de vous distraire.
Vous pouvez déplacer les tests vers une arborescence source qui n'est normalement pas incluse dans la génération.
In extremis, vous pouvez supprimer le code de la TETE du système de contrôle de version, mais cela rendra plus difficile la reconnaissance de la fin de la troisième phase.
L'objectif est d'amener Jenkins à passer au vert dès que possible, afin que vous puissiez commencer à vous déplacer dans la bonne direction dès que possible.
Gardez les tests pertinents.
Décidez d'ajouter de nouveaux tests lorsque vous ajoutez ou modifiez du code, et engagez-vous à conserver tous les tests réussis.
Les tests peuvent échouer pour diverses raisons, notamment le fait qu'ils n'étaient pas des tests bien écrits au départ. Mais une fois que vous avez obtenu Jenkins vert, il est très important de le garder ainsi.
Habituez-vous à écrire de bons tests et faites-en un gros problème si les tests échouent.
Déterminez l'intention de chaque test.
Passez les tests désactivés un par un. Commencez par ceux qui affectent les modules que vous modifiez le plus fréquemment. Déterminez l'intention du test et la raison de l'échec.
Teste-t-il une fonctionnalité qui a été supprimée de la base de code exprès? Ensuite, vous pouvez probablement le supprimer.
Attrape-t-il un bug que personne n'a encore remarqué? Rétablissez le test et corrigez le bogue.
Est-ce qu'il échoue parce qu'il faisait des hypothèses injustifiées (par exemple, en supposant que le texte du bouton serait toujours en anglais, mais maintenant vous avez localisé votre application pour plusieurs langues)? Ensuite, déterminez comment concentrer le test sur une seule chose et isoler le mieux possible des modifications non liées.
Le test s'étend-il à l'ensemble de l'application et représente-t-il un test système? Ensuite, supprimez-le de votre suite de tests Jenkins principale et ajoutez-le à la suite de régression qui s'exécute moins fréquemment.
L'architecture de l'application a-t-elle changé au-delà de la reconnaissance, de sorte que le test n'a plus rien d'utile? Supprime-le.
Le test a-t-il été ajouté pour augmenter artificiellement les statistiques de couverture du code, mais ne fait-il rien de plus que confirmer que le code se compile correctement et ne passe pas dans une boucle infinie? Ou bien, le test confirme simplement que le cadre de simulation sélectionné renvoie les résultats auxquels vous venez de le dire? Supprime-le.
En conséquence, certains tests seront maintenus, certains seront modifiés, certains seront divisés en plusieurs morceaux indépendants de la taille d'une bouchée, et certains seront supprimés. Tant que vous progressez avec de nouvelles exigences, réserver un peu de temps pour faire face à une dette technique comme celle-ci est la chose responsable à faire.