Quelle est la meilleure pratique pour gérer un test unitaire plus ancien lors du débogage ou de l'ajout d'une nouvelle fonctionnalité?

Question

J'essaie de comprendre quelle est la meilleure façon de gérer un test unitaire plus ancien qui ne correspond pas vraiment ou qui fonctionne plus pour des raisons comme des bugs ou des changements logiques dans votre code? Devons-nous simplement les ignorer et les modifier pour les adapter à la logique actuelle? Par exemple si ces tests n'ont pas été écrits par vous, et maintenant vous êtes responsable de modifier le code. Prenez-vous toujours le temps de mettre à jour ces tests pour les faire passer avant de passer à autre chose?

Ou simplement les ignorer? Merci.

Answer 1

Les tests unitaires obsolètes sont inutiles. Si vous voulez qu'ils soient utiles, mettez-les à jour.

Answer 2

Bien sûr, vous devriez prendre le temps de les faire passer. Pourquoi jeter ce travail?

L'idée de TDD est de faire passer tous les tests tout le temps. A partir du moment où vous commencez à dire, "hé, c'est correct que ce test échoue", TDD est inutile. Cela demande de la discipline, oui, mais ça vaut le coup à la fin.

Answer 3

Par exemple, si ces tests n'ont pas été écrites par vous, et maintenant vous êtes en chargé de modifier le code. Avez-vous encore le temps de mettre à jour ces test pour le faire passer avant de continuer?

Je voudrais mettre à jour les tests.

Mais d'abord je voudrais traquer le développeur qui les a cassés et ... eh bien here's some inspiration.

Answer 4

Chaque fois que je suis dans une situation similaire, il y a une telle hâte que je considère que les tests obsolètes sont inexistants. En conséquence, je considère le code comme legacy code et j'écris de nouveaux tests uniquement pour la fonctionnalité sur laquelle je travaille.

Answer 5

Il y a deux situations possibles là:

1. Un petit nombre de tests INSUFFISANT - fixer les essais
2. La plupart du test échouent et il vous faudra plus de temps pour résoudre tous les tests, à mettre en œuvre le changement - laisser tomber l'ensemble du projet de test et écrire de nouveaux tests.

Answer 6

Il n'est jamais acceptable d'avoir un test d'échec. Vos systèmes devraient rejeter toutes les chances qui n'ont pas toutes les passes de test, ou au moins un test qui échoue devrait déclencher une tâche de travail prioritaire pour le développeur qui a causé l'échec du test.

Au fil du temps, les tests deviennent obsolètes en particulier avec les produits matures. Au mieux, ils servent simplement à exercer le code. Parfois, ils échouent, mais généralement pour des raisons non liées à la raison pour laquelle ils ont été écrits en premier lieu. Vous devez utiliser votre jugement pour décider si vous voulez vous défaire d'un test obsolète ou non. Nous avons des tests de 10 000 si nous ne coupions pas occasionnellement le bois mort que les essais prendraient trop de temps à terminer.

Les outils de couverture de test peuvent vous aider à déterminer si un test particulier mérite d'être conservé ou non.

Answer 7

Lorsqu'un test échoue, il y a trois options:

1. Le code de production est cassé, et il doit être fixé.
2. Le test est défectueux (ou n'est pas à jour avec les modifications récentes du code de production), et le test doit être corrigé.
3. Le comportement spécifié par le test n'est plus nécessaire et le test peut être supprimé.

Avant d'écrire un nouveau code, tous les tests doivent réussir. Lorsque les tests échouent, vous devez les corriger immédiatement ou annuler vos modifications. Sinon, vous ne pouvez pas être sûr que lorsque les tests échouent, que ce soit à cause du changement que vous avez effectué il y a une minute, ou que ce soit simplement une fausse alarme.

Ignorer les tests défaillants est un chemin vers le côté obscur. Si vous les ignorez assez longtemps, la combinaison de test va pourrir car encore plus de tests échouent, et elle perdra sa valeur et vous devrez rejeter les tests. Et puis, quand vous ne pourrez plus compter sur la suite de tests, vous hésiterez à améliorer la conception du code de production, et le code de production commencera à pourrir. Enfin, il n'est plus possible de maintenir le code de production, et vous devrez le jeter et le réécrire.