Dois-je continuer à enregistrer un échec ?

Question

Je travaille sur une suite de tests de régression automatisés pour une application que je gère.Lors du développement du test de régression automatisé, j'ai rencontré un comportement qui est presque certainement un bug.Donc, pour l'instant, j'ai modifié le test de régression automatisé pour ne pas enregistrer d'échec - il laisse délibérément passer ce mauvais comportement, je veux dire.

Je suis donc intéressé par les avis des autres sur ce site.Évidemment, j'ajouterai un bug à notre suivi des défauts pour m'assurer que ce comportement d'erreur est corrigé.Mais existe-t-il des raisons impérieuses (dans un sens ou dans l'autre) de modifier le test de régression pour indiquer constamment un échec ou de laisser le test de régression interrompu et de ne pas échouer jusqu'à ce que nous puissions corriger le comportement défectueux ?Je considère cela comme un 6 sur une douzaine et demie de l'autre type de question, mais je pose la question ici parce que je pensais que d'autres pourraient le voir différemment.

---

@Paul Tomblin,

Juste pour être clair : je n’ai jamais envisagé de supprimer le test ;J'envisageais simplement de modifier la condition de réussite/échec pour permettre l'échec sans qu'il ne me soit lancé au visage à chaque fois que j'exécute le test.

Je suis un peu préoccupé par les échecs répétés dus à des causes connues qui finissent par être traités comme des avertissements en C++.Je connais des développeurs qui voient des avertissements dans leur code C++ et les ignorent simplement parce qu'ils pensent qu'ils ne sont que du bruit inutile.Je crains que laisser un échec connu dans la suite de régression n'incite les gens à ignorer d'autres échecs, peut-être plus importants.

BTW, de peur d'être mal compris, je considère les avertissements en C++ comme une aide importante dans la création d'un code solide, mais à en juger par les autres développeurs C++ que j'ai rencontrés, je pense que je fais partie de la minorité.

Answer 1

Je dirais "bon sang ouais!".Le simple fait est : est-ce un échec ?Oui!Ensuite, il devrait être enregistré.Vous compromettez à peu près vos tests en permettant la réussite d’un test échoué.

Une chose qui me préoccuperait personnellement, c'est que si je faisais cela et passais sous un bus, le "patch" pourrait ne pas être supprimé, ce qui signifie que même après une "correction de bug", le bug pourrait toujours persister.

Laissez-le dedans, mettez à jour vos notes de projet, peut-être même réduisez la gravité (si possible), mais ne cassez certainement pas la chose qui vérifie les choses cassées ;)

Answer 2

Si vous arrêtez de le tester, comment saurez-vous quand il sera réparé et, plus important encore, comment saurez-vous s'il est à nouveau cassé ?Je suis contre la suppression du test, car vous risquez d'oublier de le rajouter.

Answer 3

Nous avons ajouté une fonctionnalité « snooze » à nos tests unitaires.Cela a permis d'annoter un test avec un attribut qui disait essentiellement « ignorer les échecs pendant X semaines à compter de cette date ».Les développeurs pouvaient annoter un test dont ils savaient qu'il ne serait pas corrigé avant un certain temps, mais cela ne nécessitait aucune intervention ultérieure pour le réactiver manuellement, le test réapparaîtrait simplement dans la suite de tests à l'heure indiquée.

Answer 4

Cela devrait rester un échec s’il ne fait pas ce qui était attendu.

Sinon, c'est trop facile à ignorer.Gardez les choses simples : ça marche ou ça ne marche pas.Échec ou succès :)

-Kevin Fairchild

Answer 5

Bien que je sois d'accord avec la plupart de ce que Paul a dit, l'autre côté de l'argument serait que les tests de régression, à proprement parler, sont censés tester les changements dans le comportement du programme, et pas n'importe quel vieux bug.Ils sont spécifiquement censés vous avertir lorsque vous avez cassé quelque chose qui fonctionnait auparavant.

Je pense que cela se résume aux autres types de tests exécutés sur cette application.Si vous disposez d'une sorte de système de test unitaire, ce serait peut-être un endroit plus approprié pour ce test, plutôt que dans le test de régression (au moins jusqu'à ce que le bug soit corrigé).Toutefois, si les tests de régression sont vos seuls tests, je laisserais probablement le test en place.

Answer 6

Même s’il est préférable que les tests échouent lorsqu’il y a des bugs, cela s’avère souvent un choix peu pratique.Lors du premier ajout de test dans une zone, il est particulièrement facile de s'enliser dans les bugs découverts et donc de ne pas terminer l'objectif principal.De plus, les tests qui échouent depuis longtemps deviennent de plus en plus bruyants, de plus en plus faciles à ignorer.

L'écriture de tests qui échouent fait partie de la correction des bogues et n'est vraiment importante que lorsque la correction de ces bogues est importante.Cela doit être déterminé par vos priorités actuelles en matière de produit et de qualité.S'il vous arrive de produire des tests comme effet secondaire d'un autre effort, c'est bien, mais cela ne devrait pas vous distraire de vos priorités réelles.

Je recommanderais de signaler tous les bogues découverts tout en améliorant les tests en avertissements et en signalant les bogues à leur encontre.Il s'agit d'une approche globale qui vous permettra d'accomplir la tâche en cours tout en utilisant réellement ce que vous apprenez.Les tests peuvent alors facilement se transformer en véritables échecs lorsque la correction des bugs est programmée.

Contrairement à d’autres répondants, je pense que les échecs sont tout aussi faciles à ignorer que les avertissements, et le coût de la formation de votre équipe à ignorer les échecs est trop élevé pour permettre que cela se produise.Si vous produisez des tests qui échouent dans le cadre de cet effort, vous aurez détruit l'utilité de votre suite de tests de régression alors que la tâche l'améliorait.

Answer 7

Avoir un test qui échoue est en quelque sorte irritant.Il existe une différence entre un code cassé et un code inachevé, et la question de savoir si le test doit être traité immédiatement dépend des circonstances exposées par ce test défaillant.

S'il est cassé, vous devriez le réparer le plus tôt possible.S'il n'est pas terminé, résolvez-le lorsque vous en avez le temps.

Dans les deux cas, vous pouvez clairement vivre avec un mauvais comportement (pour l'instant), donc tant que le problème est enregistré, vous pourriez aussi bien ne pas le laisser vous harceler jusqu'à ce que vous ayez le temps de le résoudre.