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

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.

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. .

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.

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).

"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.

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.

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.

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.

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.

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.

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é.

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.

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.