Je construis actuellement un script de construction CI pour une application héritée. Il existe des tests Junit sporadiques disponibles et je vais intégrer une exécution junit de tous les tests dans la construction CI. Cependant, je me demande quoi faire avec les échecs de 100 ans que je rencontre dans les tests Junit non entretenus. Est-ce que je:
1) Commencez-les comme ils semblent avoir raisonnables, si une logique d'entreprise non comprise entre elles dans l'espoir que quelqu'un finit par décompose et les fixe
2) Supprimez-les comme il est peu probable que quiconque les fixera et que le code commenté ne sera ignoré ou être encombré pour Evermore
3) Tracez les personnes qui ont laissé ce gâchis dans mes mains et les frapper sur les têtes avec les impressions du code (qui en raison de l'odeur de méthode de longue méthode sera suffisamment adaptée à la tâche) tout en prêchant les avantages d'un Base de code bien entretenue et testée par unité
8 Réponses :
S'ils compilent mais échouent: laissez-les dans. Cela vous procurera une bonne histoire d'améliorations de test au fil du temps lors de l'utilisation de CI. Si les tests ne compilent pas, mais rompent la construction, commencez-les et piquez les développeurs pour les réparer.
Cela n'empêche évidemment pas l'option 3 (en les frappant sur la tête), vous devez le faire quand même, peu importe ce que vous faites avec les tests.
Si vous utilisez Junit 4, vous pouvez annoter ces tests avec @ignore Annotation .
Si vous utilisez Junit 3, vous pouvez simplement renommer des tests afin qu'ils ne commencent pas avec En outre, essayez de corriger des tests pour la fonctionnalité que vous modifiez afin de ne pas créer de code de code plus grand. test .
L'annotation @ignore est intéressante. En ce qui concerne la suppression du test du nom de la méthode, vous devez alors faire attention et ajouter un commentaire pour expliquer que ce n'est pas une méthode oubliée / inutilisée (sinon quelqu'un pourrait le supprimer), mais une méthode de test qui devrait être corrigée .
Vous pouvez renommer la méthode à quelque chose comme FixitLaterTestBlahBlah, n'est-ce pas?
Nous utilisons Junit 3 et j'avais envisagé de renommer les tests à BrokensuCandsuch, mais pour moi, cela nécessite plus de travail des futurs responsables de comprendre ce que j'ai fait et pourquoi je l'ai fait. Avec commentant ou suppression, c'est bien plus dans votre visage.
Si vous commencez les tests, il peut être possible qu'ils soient inattendus lorsque vous les déconnectez à cause des changements d'API. S'ils seront toujours motivés, vous fixerez des erreurs de compilation lorsque votre API change.
Pas besoin de commenter des choses, c'est ce que le contrôle de la révision est pour. Supprimez-les ou @ignore. Les commenter juste laisse plus de cruft.
Je ne connais pas votre position dans la société, mais si elle est possible, laissez-les et déposez les problèmes comme des erreurs dans votre système de ticket. Laissez-le aux développeurs de les réparer ou de supprimer les tests.
Si cela ne fonctionne pas, supprimez-les (vous avez le contrôle de la version, non?) Et fermez le billet avec un commentaire comme «supprimé des tests JUnit défaillants qui apparaissent ne seront apparemment pas un peu plus polis.
Le point est que les tests Junit sont du code de l'application et, à ce titre, fonctionnent. C'est ce que les développeurs sont payés. Si un test n'est plus approprié (quelque chose qui n'existe pas encore a été testé) Les développeurs doivent signaler et supprimer le test.
Suivez le Pas de fenêtre cassée Principe et Prenez une action vers une solution du problème. Si vous ne pouvez pas résoudre les tests, au moins:
puis à empêche de cette situation de se produire à l'avenir, installez une fiche similaire à Plugin de jeu Hudson . Les gens reçoivent des points affectés lors de l'intégration continue, par exemple.
Un outil vraiment cool pour créer un sentiment de
Le lien du plugin de jeu Hudson est momentané. Voici un autre lien clintshantank.javadevelopersjournal.com/ci_build_game.htm
Vous devez certainement les désactiver d'une certaine manière pour l'instant. Que ce soit fait en commentant, la suppression (supposant que vous puissiez les récupérer du contrôle de la source) ou d'autres moyens sont à vous. Vous ne voulez pas que ces tests échoués soient un obstacle pour les personnes qui tentent de soumettre de nouveaux changements.
S'il y a assez peu de choses que vous sentez que vous pouvez les réparer vous-même, c'est bien - faites-le. S'il y en a trop d'entre eux, alors je serais enclin à utiliser une approche "crowdsourcing". Déposer un bug pour chaque test d'échec. Essayez d'attribuer ces bugs aux propriétaires / auteurs réels des tests / code testé si possible, mais si cela est trop difficile à déterminer, la sélection de manière aléatoire est bien tant que vous dites aux gens de réaffecter les bugs qui leur sont attribués. Ensuite, encouragez les gens à résoudre ces insectes en leur donnant une échéance ou en notifiant périodiquement à tous les progrès et en les encourageant à réparer tous les bugs.
Un système CI en rouge stable est assez sans valeur. Le principal avantage est de maintenir une barre de qualité, et cela rend beaucoup plus difficile s'il n'y a pas de transition pour marquer une chute de qualité.
L'effort immédiat doit donc être de désactiver les tests d'échec et de créer un ticket de suivi / un élément de travail pour chacun. Chacun de ceux-ci est résolu mais vous faites triage - si personne ne se soucie du test, débarrassez-vous. Si l'échec représente un problème qui doit être adressé avant expédier, laissez le test désactivé.
Une fois que vous êtes dans cet état, vous pouvez maintenant compter sur le système CI pour vous indiquer que l'action urgente est requise - roulez le dernier changement, ou mettez immédiatement une équipe sur la correction du problème, ou autre.
Les tests Junit défaillants indiquent que
de toute façon, vous devez corriger / examiner les tests / la source. Comme cela ressemble à votre travail consiste à créer le système CI et à ne pas résoudre les tests, dans votre position, je laisserais une bombe comprise dans les tests. Vous pouvez obtenir très envie avec des méthodes annotées avec Junit 4 (quelque chose comme où @ignOreuntil (date = "2010/09/16") ) et un coureur personnalisé, alors ou vous pouvez simplement ajouter une instruction SI SI à la première ligne de chaque test: isbeforetimebomb () peut simplement vérifier la date actuelle contre une date future de votre choix. Ensuite, vous suivez les conseils donnés par d'autres ici et informez votre équipe de développement que la construction est verte maintenant, mais est susceptible d'exploser en x jours à moins que les tests fusionnés ne soient fixés.
Vous souhaitez battre les personnes qui vous ont donné le code ou les personnes qui ont écrit des tests unitaires? P.s. Les mauvais programmeurs ne peuvent comprendre que des méthodes longues.