Comment créer un environnement où la fixation des tests est considérée comme une priorité?

Je suis ingénieur logiciel dans une entreprise de taille moyenne. Nous avons une plate-forme de test assez robuste fonctionnant sur TeamCity. Il effectue des tests unitaires à chaque enregistrement et un test unitaire quotidien / exécution BVT.

Le problème est - nous avons beaucoup de tests unitaires brisés.

Très souvent, j'évoque l'inutilité des tests unitaires s'ils sont constamment cassés et non entretenus. L'impossibilité de voir si un changement a provoqué une régression supprime la majeure partie de la valeur d'une plate-forme de test unitaire.

Je voudrais faire planter une graine qui créera une culture de bonnes habitudes - fixant les tests quand ils sont cassés, les considérant comme précieux, priorisant la fixation des tests avec d'autres travaux.

J'ai essayé la corruption (produits de boulangerie!), Tout simplement demander et parler aux chefs d'équipe. Tout le monde dit que c'est une bonne idée, mais je vois que je suis le seul à y faire quoi que ce soit.

Quelle est la meilleure façon de commencer à encourager les autres à corriger leurs tests et à prioriser la fixation des tests dans leurs sprints?

S'il existe une manière moins subjective de poser cette question, je serais heureux d'accepter tout conseil.

— Codeman
source

pistolet automatique Nerf visant à briser le type de construction ...

— freak cliquet

Nous avons en fait un pistolet nerf automatique ... mais la construction n'est pas cassée, juste les tests unitaires :)

— Codeman

La rupture des tests unitaires devrait impliquer la rupture de la construction. ;)

— Jeroen Vannevel

@ Ӎσᶎ: le buy-in est important, mais vous ne pouvez pas obtenir le buy-in pour résoudre un problème tant que les gens ne sont pas conscients du problème. Dans ce cas, l'adhésion ne doit initialement provenir que des chefs d'équipe et des managers. L'adhésion des développeurs peut survenir plus tard et le sera généralement, naturellement, lorsque le système de build a été mis en place pour que les développeurs individuels paient leurs propres erreurs.

— Aaronaught

Si les beignets ont échoué, vous êtes grillé. :-)

— Ross Patterson

Réponses:

Faites en sorte qu'il soit impossible de libérer quoi que ce soit sans corriger les tests.

Échec de la génération en cas d'échec des tests.
Échec de la génération si des tests sont ignorés.
Échec de la génération si la couverture des tests est inférieure à un certain niveau (afin que les utilisateurs ne puissent pas simplement supprimer des tests pour contourner ce problème).
Utilisez le serveur CI pour faire vos builds de version, et autorisez uniquement les builds à partir du drop de build du serveur à être promus en UAT / staging / production / any.

Le fait est que si votre build est interrompu pendant plus de 15 minutes à la fois (et cela inclut les tests qui échouent), alors vous ne faites pas d'intégration continue .

L'option "nucléaire" consiste à demander à votre serveur de contrôle de source de refuser les validations / enregistrements de tout utilisateur autre que celui qui a interrompu la génération. De toute évidence, un administrateur doit être en mesure de passer outre temporairement si cette personne part en vacances - mais, si tout le monde sait que toute l'équipe est foutue jusqu'à ce qu'elle corrige ses tests, alors elle le résoudra rapidement.

Une bonne politique (qui est encore meilleure lorsqu'elle est automatisée) consiste à rétablir la source sur le dernier commit stable connu après 15 minutes d'échec de la construction. En d'autres termes, si vous ne pouvez pas le réparer, ou si vous ne savez pas ce qui a causé la rupture de la construction ou du test, puis revenez en arrière et travaillez localement jusqu'à ce qu'il soit résolu - ne faites jamais en sorte que d'autres développeurs tournent le pouce pendant que vous broyez un problème dont ils ne se soucient pas.

PS Si vous déjà avez beaucoup de tests ayant échoué, vous pouvez utiliser un « seuil de fuite » dans CI. Configurez-le de sorte que la génération échoue uniquement s'il y a plus d'échecs de test que la dernière fois. Ceci, associé à une règle de couverture, forcera les développeurs à éventuellement améliorer la situation de test s'ils veulent pouvoir continuer à travailler.

PPS Je réalise que cela peut sembler draconien pour certains, mais tout dépend de votre culture. Si vous arrivez à un point où les gens ne quittent pas la version cassée ou les tests échouent (mon équipe ne le fait presque jamais, bien que je doive parfois le leur rappeler), alors vous n'avez pas besoin de continuer avec l'ensemble de règles le plus strict. Bien que l'OMI, vous devriez toujours échouer la construction sur un test unitaire cassé. Les tests d'intégration / de navigateur peuvent parfois échouer.

— Aaronaught
source

Bien que toutes vos astuces techniques soient utiles, je pense que la partie la plus précieuse de votre réponse est que «c'est toute votre culture» car plus qu'un problème de discipline, c'est un problème d'utilité perçue du test. Je préfère le mettre en avant que dans un PPS

— user40989

@ user40989: Je vous entends. Mais la culture est quelque chose que vous devez cultiver. Si vous voulez que les gens comprennent l'importance des tests, vous devez parfois faire en sorte que les gens ne puissent pas les ignorer. Une fois que les gens s'habitueront à un niveau élevé de couverture de code et de tests écologiques, ils ne voudront plus revenir en arrière, puis vos propres développeurs l'appliqueront aux nouvelles recrues. Et bien, j'espère. Un chef d'équipe rétentif anal et / ou un maître et / ou un gestionnaire de construction aide. :)

— Aaronaught

FWIW: L'ensemble de notre processus de sortie est maintenant automatisé et les gens ne penseraient pas à avoir des tests cassés. Le chef d'équipe effectue une fusion vers le maître, puis démarre une build de version et envoie une demande de promotion aux administrateurs système qui poussent littéralement un bouton pour déployer à partir des artefacts de build et exécuter des tests de navigateur et d'API automatisés. Personne ne se plaint de ce processus, jamais, car il fait gagner du temps - nous avions l'habitude de passer 2 semaines à discuter d'une version, maintenant c'est essentiellement une onde de main. C'est ce que je veux dire en cultivant la culture - tout le monde sait que les 2 minutes supplémentaires pour corriger un test permettront d'économiser 2 heures plus tard.

— Aaronaught

Les tests unitaires qui échouent ne sont pas le problème. Ils sont un symptôme .

Le vrai problème est dans la culture. Vous devez marcher doucement: voici des dragons . Vous ne pouvez pas changer la culture par vous-même, et être la roue grinçante, en fin de compte, fera de vous un paria. Littéralement.

Je suggère que si vous essayez de trouver une personne âgée pour défendre la cause et montrer la voie. Si cela échoue, essayez de le soulever lors d'une réunion générale des développeurs, sans pointer du doigt ni appeler des noms. Une autre alternative consiste à prendre vous-même la responsabilité de faire un travail correct: il suffit de corriger quelques tests supplémentaires chaque fois que vous effectuez un enregistrement. Gardez un tableau sur le mur indiquant le nombre d'échecs de tests au fil du temps. D'autres le verront: peut-être qu'ils accepteront.

Il n'y a pas de réponse facile.

— andy256
source

Être la roue grinçante m'a fait devenir chef d'équipe. Peut-être qu'il y avait un problème avec votre couinement? Sérieusement, cela parle d'un problème de culture très différent , non pas avec l'équipe de développement, mais avec la direction de l'entreprise. Si la réponse de la direction à un incendie brûlant est de mettre des lunettes de soleil, alors sortez de là. Mais si vous êtes en fait un magasin de développement , par opposition à un service informatique d'entreprise produisant des logiciels à partir d'un centre de coûts, il est assez probable que les gestionnaires se soucient de la fréquence et de la sécurité de la mise sur le marché.

— Aaronaught