Dois-je intentionnellement interrompre la construction lorsqu'un bogue est détecté en production?


410

Il me semble raisonnable de penser que si un utilisateur sérieux trouve un bug sérieux dans la production, un test unitaire en échec doit être ajouté pour couvrir ce bug, interrompant ainsi intentionnellement la construction jusqu'à ce que le bug soit corrigé. Mon raisonnement est que la construction aurait dû échouer depuis le début , mais pas à cause d'une couverture de test automatique inadéquate.

Plusieurs de mes collègues ont exprimé leur désaccord en affirmant qu'un test unitaire échoué ne devrait pas être enregistré. Je souscris à ce point de vue en ce qui concerne les pratiques normales de TDD, mais je pense que les bogues de production doivent être traités différemment - après tout, pourquoi voudriez-vous autoriser une construction pour réussir avec des défauts connus?

Est-ce que quelqu'un d'autre a des stratégies éprouvées pour gérer ce scénario? Je comprends que le fait de briser intentionnellement le build pourrait perturber d'autres membres de l'équipe, mais cela dépend entièrement de la manière dont vous utilisez les branches.


75
+1; une question très provocante. Je peux voir les deux côtés.
Carl Manaster

28
Vous utilisez le terme "la construction" pour inclure "les tests", ce qui n’est pas une compréhension universelle.
Jay Bazuzi

19
Si vous faites TDD, vous écrirez le test qui a échoué, corrigez le code puis archivez . Ainsi, vous évitez une construction cassée.
dietbuddha

7
Dans la même logique, vous devez arrêter les instances actives des clients jusqu'à ce que le problème soit résolu. Non, vous ne devriez pas casser la construction. Laissez le développeur qui gère le bogue ajouter le test unitaire et le code change ensemble. Pas besoin de fermer tout le processus.
Thanos Papathanasiou

Réponses:


412

Notre stratégie est la suivante:

Enregistrez 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 construction ne casse pas.

Bien sûr, vous notez le test ignoré dans la base de données de bogues, il @Ignoreest donc supprimé une fois le test corrigé. Cela sert également de vérification facile pour la correction de bogue.

Le point de départ de la construction de tests échoués n’est pas de mettre l’équipe sous pression, mais bien de l’alerter sur un problème. Une fois que le problème est identifié et classé dans la base de données de bogues, il est inutile de lancer le test pour chaque construction: vous savez que cela échouera.

Bien sûr, le bogue devrait toujours être corrigé. Mais la planification du correctif est une décision commerciale, et donc pas vraiment une 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 propriétaire du produit / client me dise qu'il veut le réparer. .


150
+1 Je pense que vous cliquez sur le bouton «Planifier le correctif est une décision commerciale» - en tant que développeur, ce n’est pas à moi de décider si un bogue casse la construction.
MattDavey

22
Je pense que c'est une solution très judicieuse. Surtout si le prochain gars à vérifier un code mineur, obtient soudainement un avis de "test échoué" et pense que c'est quelque chose qu'il a fait.
Holger

14
"Pour moi, une fois qu'un bogue est classé dans la base de bogues, ce n'est plus mon problème" ... +1
Jake Berger

20
@anon sauf chez Toyota. Un opérateur de ligne constate un défaut puis tire sur le cordon andon. Toute l’installation s’arrête, la direction prend le relais et la ligne n’est redémarrée que lorsque le problème est résolu. Google Andon Cord. Ce n'est pas un nouveau concept. voir: startuplessonslearned.com/2008/09/…
Christopher Mahan le

4
@AndresJaanTack: Cela dépendra bien sûr de votre méthodologie, mais en général, je ne suis pas d'accord. Au moins dans un contexte professionnel, la planification du travail est une décision commerciale, ce qui inclut la correction des bogues . Parfois, une nouvelle fonctionnalité (ou la publication à une certaine date) peut être plus utile que la correction d'un bogue (mineur) - dans ce cas, la correction du bogue doit être différée. "Corriger le bogue maintenant" serait inapproprié dans cette situation, car cela retarderait le travail plus important.
Sleske

106

Pourquoi voudriez-vous permettre à une compilation de réussir avec des défauts connus?

Parce que parfois, vous avez des contraintes de temps. Ou le bogue est si mineur qu'il ne vaut pas la peine de retarder l'expédition du produit de quelques jours pour le tester et le réparer.

Aussi, à quoi sert-il de briser intentionnellement la construction chaque fois que vous trouvez un bogue? 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 étant très important dans votre système de suivi des bogues.


Je comprends ce que vous dites, et je suis généralement d’accord avec vous - mais dans ce cas, nous parlons d’un grave bogue qui est entré en production et qui a été rencontré par les utilisateurs finaux: s
MattDavey

3
Voir le deuxième paragraphe de ma réponse.
Arseni Mourzenko

8
Je comprends, je pense que le point est résumé dans votre premier paragraphe - ce n’est pas au développeur de juger de la gravité du bogue, ni de savoir si c’est un révélateur, c’est une décision qui appartient à l’ensemble des entreprises.
MattDavey

4
La question est quelle est la priorité de ce bogue? Cela pourrait être un OMG FIX IT NOW, il pourrait être Oui, c'est ennuyeux que nous devrions le réparer à un moment donné, il pourrait être quelque chose au milieu. Mais tous les insectes ne vont pas frapper au même endroit sur ce spectre.
Zachary K

55

Les tests sont là pour vous assurer que vous n’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 l'échec des tests n'est pas seulement une indication de bogues, mais également une indication d'échec du processus de développement (de la négligence à une dépendance mal identifiée).


20
"La liste des tests ayant échoué ne remplace pas un système de suivi des bogues" +1, c'est aussi un très bon point :)
MattDavey

1
Je suggèrerais d'avoir des tests unitaires de régression entrer le code base dans le cadre de la correction de bug, pas plus tôt.
yrk

6
@yarek: Les tests de régression peuvent aller dans la base de code à tout moment, il suffit de les ignorer jusqu'à ce que le bogue soit corrigé. Je les développe habituellement tout en diagnostiquant le problème, car ils peuvent alors servir d’aide au débogage.
Sleske

C’est un bon exemple de la raison pour laquelle «casser le bâti» devient une partie toxique d’un lieu de travail où l’IC devient un simple «développement axé sur le blame». J'ai assisté à de nombreuses réunions au cours desquelles le PHB a commencé à parler de "négligence", comme si c'était la raison pour laquelle la construction avait éclaté. Dans un tel environnement, vous ne feriez probablement pas intentionnellement l'enregistrement de quelque chose qui aurait cassé la construction. Sinon, le PHB va se fâcher. Casser la construction, porter le cône de honte. Quelle pratique de merde.
Warren P

@WarrenP, il y a parfois d'autres problèmes, mais soyons clairs, la négligence est la première raison pour laquelle la construction se casse. Si vous savez que quelque chose casse la construction, pourquoi l'enregistrer?
AProgrammer

23

"Casser la construction" signifie empêcher une compilation de se terminer correctement . Un test qui échoue ne fait pas ça. C'est une indication que la construction a des défauts connus, ce qui est tout à fait correct.

La plupart des serveurs de build suivent l’état des tests dans le temps et attribueront une classification différente à un test en échec depuis sa création par rapport à une régression (le test réussissait et échouait), ainsi que la révision dans laquelle la régression a eu lieu.


12
Ce n'est pas toujours correct, souvent les équipes considèrent un test manquant comme une construction cassée - en fait, la plupart des équipes que j'ai vues récemment le font (c'est une pratique agile typique). Avec la plupart des équipes agiles, un test qui échoue est un cas où vous arrêtez la ligne - toute l'équipe s'attaque au problème et le résout. Je suppose que je pourrais prendre votre message pour signifier que la réponse doit être basée sur vos pratiques, auquel cas c'est tout à fait exact.
Bill K

2
Je considère toujours qu'un test ayant échoué signifie que la construction a échoué.
John Saunders

@ JohnSaunders: Mais ce n'est pas ce que cela signifie. Comme je l'ai dit dans ma réponse, cela signifie "la version présente des défauts connus".
Ben Voigt

1
@ho dit qu'il n'y avait pas de tests? Où as tu obtenu ça? Je veux dire que ma première étape après avoir trouvé le bogue n’est pas d’empêcher la construction de réussir, mais plutôt de créer un rapport de bogue détaillé. Lorsque le bogue est corrigé, il devrait tout d'abord y avoir un test unitaire échoué.
John Saunders

1
J'ai un petit problème avec la création immédiate d'un test qui échoue. Je ne veux tout simplement pas qu'il soit enregistré dans l'ensemble des tests qui seront exécutés lors de la construction. Je souhaite également que le développeur qui corrige le bogue puisse ignorer ce test. Dans la plupart des endroits où j'ai travaillé, les personnes qui créent le rapport de bogue ne créeront pas de tests unitaires.
John Saunders

16

Je dirais que le test d'échec devrait être ajouté, mais pas explicitement en tant que "test d'échec".

Comme @BenVoigt le souligne dans sa réponse , un test qui échoue ne "brise pas nécessairement la construction". J'imagine que la terminologie peut varier d'une équipe à l'autre, mais le code est toujours compilé et le produit peut toujours être livré avec un test qui échoue.

Ce que vous devriez vous demander dans cette situation est,

Quels sont les tests destinés à accomplir?

Si les tests existent uniquement pour que tout le monde se sente bien à propos du code, l'ajout d'un test d'échec pour que tout le monde se sente mal à propos du code ne semble pas productif. Mais ensuite, dans quelle mesure les tests sont-ils productifs?

Mon affirmation est que les tests doivent refléter les exigences de l’entreprise . Ainsi, si un "bogue" indiquant qu'une exigence n'est pas correctement remplie a été trouvé, cela signifie également que les tests ne reflètent pas correctement ou totalement les exigences de l'entreprise.

C'est le bogue à corriger en premier. Vous n'êtes pas "ajouter un test qui échoue". Vous corrigez les tests pour qu'ils reflètent 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 corrigés, cette priorité peut-elle vraiment être déterminée? L’entreprise doit savoir exactement ce qui échoue, comment il échoue et pourquoi elle échoue afin de prendre des décisions en priorité. Les tests devraient l'indiquer.

Avoir des tests qui ne passent pas complètement n'est pas une mauvaise chose. Cela crée un grand artéfact de problèmes connus à hiérarchiser et à gérer en conséquence. Avoir des tests qui ne testent pas complètement , cependant, est un problème. Cela remet en question la valeur des tests eux-mêmes.

Pour le dire autrement ... La construction est déjà cassée. Tout ce que vous décidez, c'est s'il faut ou non attirer l'attention sur ce fait.


1
Votre affirmation est fausse, les tests unitaires ne correspondent pas nécessairement directement aux exigences de l'entreprise, contrairement aux tests fonctionnels ou de bout en bout, mais le PO parlait de tests unitaires / TDD.
John Buchanan

@JohnBuchanan: Quels sont les tests destinés à valider, sinon que le logiciel fait ce qu'il est censé faire? (C'est-à-dire qu'il répond aux exigences.) Il existe, comme vous le dites, d'autres formes de tests en dehors des tests unitaires. Mais je ne vois pas l'intérêt des tests unitaires qui ne permettent pas de conclure que ce logiciel répond aux besoins de l'entreprise.
David

1
@JohnBuchanan - il n'a pas dit "les tests SONT un reflet des exigences de l'entreprise", il a dit "DEVRAIT ÊTRE". Ce qui est vrai, mais discutable. Vous avez raison de prétendre que ce n'est pas toujours le cas - certaines personnes écrivent des tests unitaires qui ne correspondent pas aux exigences de l'entreprise - bien que (à mon avis) elles aient tort de le faire. Si vous voulez affirmer que l'affirmation de David est fausse, vous pourriez expliquer pourquoi.
Dawood ibn Kareem

13

Dans notre équipe d'automatisation des tests, nous enregistrons les tests ayant échoué tant qu'ils échouent à cause 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é. Casser 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.


4
Je pense que l’idée de @ MattDavey est excellente, et j’ai défendu cela dans le passé. J'ai toujours rencontré un mur de pierre de résistance - "vous ne devriez jamais casser le bâtiment!". L'idée que la construction est déjà brisée dans cette situation semble impossible à comprendre. Malheureusement, il ne s'agit là que d'un autre cas où une bonne idée (essais automatiques et construction nette) est devenue une pratique de culte du fret dont les adhérents connaissent la règle, mais pas la raison.
Tom Anderson

3
Une idée à laquelle j’ai pensé est que l’équipe d’assurance qualité (si elle est assez technique pour écrire des tests) devrait être autorisée à écrire des tests manquants pour les bogues et à les archiver. L’obsession des développeurs pour la barre verte conduirait alors absolument donner la priorité à la correction des bogues plutôt qu’à l’ajout de fonctionnalités, ce qui est la bonne façon de développer.
Tom Anderson

Mais ceux-ci ne doivent pas être des tests unitaires qui seront exécutés pendant la construction. Si votre environnement contient un système de gestion de test pour l'assurance qualité (tel que Microsoft Test Manager), il est certain qu'un ou plusieurs cas de test doivent être ajoutés et liés au bogue, mais cela n'empêcherait pas la construction de réussir - ce serait simplement un test cas qui doit passer avant que le bogue soit considéré comme "Terminé".
John Saunders

7

Ecrire un test qui échouera jusqu'à ce que le bogue soit corrigé est une bonne idée, c'est la base de TDD.

Casser la construction est une mauvaise idée. Pourquoi? Parce que cela signifie que rien ne peut avancer tant que rien n’a été corrigé. 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? Et 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 à résoudre et que vous trouvez un autre bogue avec une priorité plus élevée? Est-ce que vous cassez également 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 construction. C’est une décision que l’équipe de développement doit prendre (peut-être avec une discussion de la direction) pour évaluer les avantages et les inconvénients de la publication d’un build contenant des bogues connus. Ceci est très courant dans le développement logiciel, pratiquement tous les logiciels majeurs sont publiés avec au moins quelques problèmes connus.


5

Cela dépend du rôle que les tests sont supposés jouer et de la manière dont leurs résultats sont supposés affecter le système / processus de construction adopté. Ma compréhension de casser la construction est la même que celle de Ben, et en même temps, nous ne devrions pas sciemment enregistrer dans du code qui rompt les tests existants. Si ces tests arrivaient "plus tard", il serait peut-être "correct" de les ignorer juste pour le rendre moins inutilement perturbant pour les autres, mais je trouve cette pratique d'ignorer les tests qui échouent (de sorte qu'ils semblent réussir) plutôt que dérangeante pour les tests unitaires), sauf s’il existe un moyen d’indiquer que ces tests ne sont ni rouges ni verts.


"sauf s'il est possible d'indiquer de tels tests comme étant ni rouges ni verts" Juste pour mémoire: la plupart des frameworks de tests unitaires distinguent les tests rouge, vert et ignoré. Au moins JUnit et TestNG le font (ils signalent "xx test, x échoué, x ignoré").
Sleske

@sleske ce serait l'idéal, je veux juste être sûr que le fait d'ignorer les échecs ne se transforme pas automatiquement en succès
prusswan

N'y a-t-il pas des constructions JAUNES? (Rouge / vert / jaune) dans Hudson / Jenkins, le régulateur de vitesse et tous les autres gros porteurs?
Warren P

@Warren P ça marche quand les gens ignorent les tests correctement, mais que certains ignorent en les rendant verts
prusswan

5

Cela dépend du bogue, bien sûr, mais en général, si quelque chose qui ne va pas a été détecté lors des tests manuels ou automatisés, cela implique une lacune dans votre couverture. J'encourage vivement à rechercher la cause du problème et à imposer un cas de test unitaire au-dessus du problème.

S'il s'agit d'un problème de production pour lequel un correctif logiciel est prévu pour 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 par erreur le correctif avec une résolution de conflit de fusion trop zélée. .

De plus, en fonction de 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 de l'encodage du fichier. corriger les exigences dans les nouveaux tests unitaires.


5

Un problème lié à l'ajout d'un test de connaissance de l'échec à la génération est que votre équipe peut prendre l'habitude d'ignorer les tests ayant échoué car elle s'attend à ce que la génération échoue. Cela dépend de votre système de compilation, mais si un test qui échoue ne signifie pas toujours "quelque chose vient de tomber en panne", il est facile de faire moins attention aux tests qui échouent.

Vous ne voulez pas aider votre équipe à entrer dans cet état d'esprit.

Donc, je suis d’accord avec sleske pour dire que vous devriez ajouter le test, mais le marquer comme "ignoré" aux fins de la construction automatique, jusqu’à ce que le bogue soit corrigé.


1
Votre logiciel de test devrait vous dire quand quelque chose vient de se rompre, par rapport à un test qui a déjà échoué.
Ben Voigt

4

Bien que je pense que vous devriez en quelque sorte «vérifier» le bogue en tant que test, pour que cela ne se reproduise plus, et en quelque sorte qu'il soit priorisé, je pense qu'il est préférable de ne pas casser la construction (/ les tests) . La raison en est que, par la suite, les mises à jour de construction seront cachées derrière votre test cassé. Donc, en enregistrant un bogue pour ce bogue, vous demandez à toute l'équipe de mettre son travail de côté pour résoudre ce bogue. Si cela ne se produit pas, vous pourriez vous retrouver avec 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é pour votre équipe de ne pas avoir de tests en attente.


4

Une autre option consiste à vérifier le test ayant échoué dans une branche distincte de votre système de contrôle de code source. En fonction de vos pratiques, cela peut être réalisable ou non. Nous ouvrons parfois une nouvelle branche pour les travaux en cours, par exemple pour corriger un bogue qui n’est pas trivial.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.