Dois-je intentionnellement interrompre la construction lorsqu'un bug est détecté en production?
Il me semble raisonnable que si un bogue sérieux est trouvé en production par les utilisateurs finaux, un test unitaire défaillant devrait être ajouté pour couvrir ce bogue, interrompant ainsi intentionnellement la construction jusqu'à ce que le bogue soit corrigé. Ma justification est que la construction aurait dû échouer tout le long, mais n'était pas due à une couverture de test automatisée inadéquate.
Plusieurs de mes collègues ont exprimé leur désaccord en disant qu'un test unitaire défaillant ne devrait pas être enregistré. Je suis d'accord avec ce point de vue en termes de pratiques TDD normales, mais je pense que les bogues de production devraient être traités différemment - après tout, pourquoi voudriez-vous autoriser une construction pour réussir avec des défauts connus?
Quelqu'un d'autre a-t-il des stratégies éprouvées pour gérer ce scénario? Je comprends que la suppression intentionnelle de la version peut perturber les autres membres de l'équipe, mais cela dépend entièrement de la façon dont vous utilisez les branches.
Notre stratégie est:
Archivez un test qui a échoué, mais annotez-le avec @Ignore("fails because of Bug #1234").
De cette façon, le test est là, mais la version ne se casse pas.
Bien sûr, vous notez le test ignoré dans la base de données des bogues, donc le @Ignore est supprimé une fois le test corrigé. Cela sert également à vérifier facilement la correction de bogue.
Le but de briser la construction en cas d'échec des tests n'est pas de mettre en quelque sorte l'équipe sous pression - c'est de les alerter d'un problème. Une fois que le problème est identifié et classé dans la base de données de bogues, il n'y a aucun intérêt à faire exécuter le test pour chaque build - vous savez qu'il échouera.
Bien sûr, le bug doit toujours être corrigé. Mais la planification du correctif est une décision commerciale, et donc pas vraiment la préoccupation du développeur ... Pour moi, une fois qu'un bogue est classé dans la base de données de bogues, ce n'est plus mon problème, jusqu'à ce que le client/propriétaire du produit me dise qu'il veut le corriger .
Pourquoi voudriez-vous permettre à une build de réussir avec des défauts connus?
Parce que parfois, vous avez des contraintes de temps. Ou le bug est si mineur qu'il ne vaut pas vraiment la peine de retarder l'expédition du produit pendant quelques jours nécessaires pour le tester et le réparer.
De plus, quel est l'intérêt de casser intentionnellement la build chaque fois que vous trouvez un bug? Si vous l'avez trouvé, corrigez-le (ou attribuez-le à la personne qui le réparera), sans déranger toute votre équipe. Si vous voulez vous rappeler de corriger un bogue, vous devez le marquer comme très important dans votre système de suivi des bogues.
Des tests sont là pour vous assurer que vous ne (ré) introduisez pas de problèmes. La liste des tests ayant échoué ne remplace pas un système de suivi des bogues. Il y a une certaine validité dans le POV que les tests qui échouent ne sont pas seulement une indication de bogues, ils sont également une indication d'échec du processus de développement (de la négligence à une dépendance mal identifiée).
"Casser la build" signifie pour empêcher une build de se terminer avec succès. Un test qui échoue ne fait pas ça. C'est une indication que la construction a des défauts connus, ce qui est exactement correct.
La plupart des serveurs de build suivent l'état des tests au fil du temps et attribuent une classification différente à un test qui a échoué depuis qu'il a été ajouté par rapport à une régression (test qui réussissait et qui ne le fait plus), et détecte également la révision dans laquelle le une régression a eu lieu.
Je dirais que le test d'échec devrait être ajouté, mais pas explicitement comme "un test d'échec".
Comme @BenVoigt le fait remarquer dans sa réponse , un test qui échoue ne "casse pas la construction". Je suppose que la terminologie peut varier d'une équipe à l'autre, mais le code compile toujours et le produit peut toujours être livré avec un test qui échoue.
Ce que vous devez vous demander dans cette situation,
Quels sont les tests censés accomplir?
Si les tests sont là juste pour que tout le monde se sente bien avec le code, ajouter un test qui échoue juste pour que tout le monde se sente mal avec le code ne semble pas productif. Mais alors, dans quelle mesure les tests sont-ils productifs en premier lieu?
Mon affirmation est que les tests doivent être le reflet des besoins de l'entreprise . Donc, si un "bug" a été trouvé qui indique qu'une exigence n'est pas correctement remplie, alors c'est aussi une indication que les tests ne reflètent pas correctement ou entièrement les exigences de l'entreprise.
Ça est le bug à corriger en premier. Vous n'êtes pas en "ajoutant un test qui échoue". Vous corrigez les tests pour refléter plus précisément les besoins de l'entreprise. Si le code ne réussit pas ces tests, c'est une bonne chose. Cela signifie que les tests font leur travail.
La priorité de la fixation du code doit être déterminée par l'entreprise. Mais jusqu'à ce que les tests soient fixés, cette priorité peut-elle vraiment être déterminée? L'entreprise doit être armée de la connaissance exacte de ce qui échoue, comment il échoue et pourquoi il échoue afin de prendre ses décisions sur la priorité. Les tests devraient l'indiquer.
Avoir des tests qui ne réussissent pas complètement n'est pas une mauvaise chose. Il crée un grand artefact de problèmes connus à hiérarchiser et à gérer en conséquence. Cependant, avoir des tests qui ne sont pas entièrement test est un problème. Elle remet en cause la valeur des tests eux-mêmes.
Pour le dire autrement ... Le build est déjà cassé. Tout ce que vous décidez est d'attirer ou non l'attention sur ce fait.
Dans notre équipe d'automatisation des tests, nous vérifions les tests qui échouent tant qu'ils échouent en raison d'un défaut du produit plutôt que d'un défaut du test. De cette façon, nous avons la preuve pour l'équipe de développement que hé, ils l'ont cassé. Rompre la construction est très mal vu, mais ce n'est pas la même chose que de vérifier des tests parfaitement compilables mais qui échouent.
Écrire un test dont vous savez qu'il échouera jusqu'à ce que le bogue soit corrigé est une bonne idée, c'est la base de TDD.
Rompre la construction est une mauvaise idée. Pourquoi? Parce que cela signifie que rien ne peut bouger tant qu'il n'est pas réparé. Il bloque essentiellement tous les autres aspects du développement.
exemple 1
Que se passe-t-il si votre application est de grande taille, avec de nombreux composants? Que faire si ces composants sont travaillés par d'autres équipes avec leur propre cycle de publication? Dure! Ils doivent attendre votre correction de bogue!
exemple 2
Que faire si le premier bogue est difficile à corriger et que vous trouvez un autre bogue avec une priorité plus élevée? Avez-vous également rompu la construction du deuxième bogue? Maintenant, vous ne pouvez pas construire tant que les deux ne sont pas corrigés. Vous avez créé une dépendance artificielle.
Il n'y a aucune raison logique pour laquelle l'échec d'un test devrait arrêter une génération. C'est une décision que l'équipe de développement doit prendre (peut-être avec une discussion de gestion) pesant les avantages et les inconvénients de la publication d'une version avec des bogues connus. Ceci est très courant dans le développement de logiciels, à peu près tous les principaux logiciels sont publiés avec au moins certains problèmes connus.
Cela dépend du bogue, bien sûr, mais généralement si quelque chose s'est mal passé qui n'a pas été identifié lors des tests manuels ou automatisés, cela implique qu'il y a un écart dans votre couverture. J'encouragerais certainement à déterminer la cause première et à gifler un cas de test unitaire au-dessus du problème.
S'il s'agit d'un problème de production qui est prévu pour un correctif à partir d'une branche de maintenance, vous devez également vous assurer que le correctif fonctionne sur la ligne principale et qu'un développeur ne peut pas supprimer le correctif par erreur avec une résolution de conflit de fusion trop zélée. .
De plus, selon votre politique de publication, la présence de tests unitaires récemment mis à jour peut aider à confirmer qu'un développeur a réellement résolu le problème, plutôt que de simplement le modifier [(le problème ou les tests?)], Bien que cela dépende d'avoir codé le exigences correctes dans les nouveaux tests unitaires.
Cela dépend du rôle que les tests sont censés jouer et de la façon dont leurs résultats sont censés affecter le système/processus de construction adopté. Ma compréhension de la rupture de la construction est la même que celle de Ben, et en même temps, nous ne devrions pas sciemment archiver du code qui rompt les tests existants. Si ces tests sont arrivés "plus tard", il pourrait être "correct" de les ignorer juste pour les perturber moins inutilement pour les autres, mais je trouve cette pratique d'ignorer les tests qui échouent (afin qu'ils semblent passer) plutôt inquiétante (surtout si pour les tests unitaires), sauf s'il existe un moyen d'indiquer que ces tests ne sont ni rouges ni verts.
L'ajout d'un test de défaillance à la génération pose un problème: votre équipe peut avoir l'habitude d'ignorer les tests qui échouent car elle s'attend à ce que la génération échoue. Cela dépend de votre système de construction, mais si un test qui échoue ne signifie pas toujours "quelque chose vient de se casser", il est facile de faire moins attention aux tests qui échouent.
Vous ne voulez pas aider votre équipe à adopter cet état d'esprit.
Je suis donc d'accord avec sleske que vous devriez ajoutez le test, mais marquez-le comme 'ignoré' aux fins de la construction automatique, jusqu'à ce que le bug soit corrigé.
Bien que je pense que vous devriez en quelque sorte `` archiver '' le bogue en tant que test, afin que lorsque vous le corrigez, il ne se reproduise plus, et en quelque sorte le prioriser, je pense qu'il est préférable de ne pas casser la construction (/ les tests) . La raison en est que les validations ultérieures seront masquées derrière votre test cassé. Donc, en vérifiant un test cassé pour ce bogue, vous exigez que toute l'équipe mette son travail de côté pour corriger ce bogue. Si cela ne se produit pas, vous risquez de casser des commits qui ne sont pas traçables en tant que tels.
Par conséquent, je dirais qu'il vaut mieux le valider en tant que test en attente et en faire une priorité dans votre équipe de ne pas avoir de tests en attente.
Une autre option consiste à archiver le test ayant échoué dans une branche distincte de votre système de contrôle de source. Selon vos pratiques, cela peut être faisable ou non. Nous ouvrons parfois une nouvelle branche pour le travail en cours, comme la correction d'un bug qui n'est pas anodin.