Tests unitaires et d'intégration: comment devenir un réflexe

Tous les programmeurs de mon équipe connaissent les tests unitaires et les tests d'intégration. Nous avons tous travaillé avec. Nous avons tous des tests écrits avec. Certains d'entre nous ont même ressenti un sentiment accru de confiance dans son propre code.

Cependant, pour une raison quelconque, la rédaction de tests unitaires / d'intégration n'est devenue un réflexe pour aucun des membres de l'équipe. Aucun de nous ne se sent vraiment mal quand il n'écrit pas des tests unitaires en même temps que le code réel. En conséquence, notre base de code est principalement découverte par des tests unitaires, et les projets entrent en production non testés.

Le problème avec cela, bien sûr, c'est qu'une fois que vos projets sont en production et fonctionnent déjà bien, il est pratiquement impossible d'obtenir du temps et / ou du budget pour ajouter des tests unitaires / d'intégration.

Les membres de mon équipe et moi-même connaissons déjà la valeur des tests unitaires ( 1 , 2 ), mais cela ne semble pas aider à intégrer les tests unitaires dans notre flux de travail naturel. D'après mon expérience, rendre les tests unitaires et / ou une couverture cible obligatoires se traduit par des tests de mauvaise qualité et ralentit les membres de l'équipe simplement parce qu'il n'y a pas de motivation auto-générée pour produire ces tests. De plus, dès que la pression diminue, les tests unitaires ne sont plus écrits.

Ma question est la suivante: y a-t-il des méthodes que vous avez expérimentées qui aident à créer une dynamique / un élan au sein de l'équipe, conduisant les gens à vouloir naturellement créer et maintenir ces tests?

Aucun de nous ne se sent vraiment mal quand il n'écrit pas des tests unitaires en même temps que le code réel.

C'est le point que vous devez aborder. La culture de votre équipe doit changer de sorte que ne pas écrire de tests pendant le sprint (ou quelle que soit l'unité de temps que vous utilisez) devienne autant une odeur de code que des valeurs codées en dur. Une grande partie de cela implique la pression des pairs. Personne ne veut vraiment être considéré comme inférieur aux normes.

Faites les tests vous-même. Vous vous réprimandez visiblement lorsque vous ne les faites pas. Indiquez où un "bon" programmeur aurait pu détecter ce bogue s'il avait écrit des tests unitaires. Personne ne veut être mauvais. Faites en sorte que ce comportement indésirable soit mauvais et que les gens suivent.

Obtenir une équipe entière à tous réellement veulent la même chose peut être assez difficile. Il arrive souvent que voir la valeur de quelque chose ne soit pas suffisant en soi pour encourager les gens à changer de comportement enraciné. Même ceux qui apprécient le changement et qui le souhaitent spécifiquement peuvent parfois aussi être responsables de le combattre inconsciemment.

Il s'agit vraiment d'une question de motivation individuelle et non de motivation d'équipe en tant que telle. Il arrive un moment où un moment de clarté vous parvient, soit à la suite de quelque chose que vous avez finalement compris, soit à cause d'un nouvel outil ou d'une autre chose subjective qui fait que le programmeur moyen jette tout et change complètement le processus. Votre travail - si vous choisissez de le faire sauf - est de voir s'il existe un moyen pour vous ou l'équipe de découvrir quels éléments seront les déclencheurs de clarté pour chaque membre individuel de l'équipe.

Pour moi personnellement, c'était simplement découvrir le framework StoryQ pour BDD dans DotNet, qui le rendait trop facile à ignorer, et m'a complètement dépassé la "barrière" test-premier vs test-simultanément. Plus tard, mes choix ont été réaffirmés lorsque j'ai trouvé NCrunch pour Visual Studio. La moitié de la bataille n'est parfois pas de vendre l'idée, mais plutôt de simplement réduire l'effort requis pour introduire un changement radical dans les habitudes ... et même alors, cela peut prendre un peu de temps et de travail. Ces mêmes déclencheurs personnels n'étaient cependant pas suffisants pour influencer l'approche de mes collègues de l'époque, qui écrivent toujours autant de leur code de test simultanément ou même après leur code d'implémentation.

Parfois aussi, il y a une réticence à changer la façon dont les choses sont faites, en raison d'une peur inhérente, d'une méfiance ou d'une vision désagréable de l'effort requis pour apprendre à faire quelque chose différemment, même lorsque le raisonnement pour le changement est solide. Si l'ensemble de votre plate-forme de test est outillé pour fonctionner d'une manière spécifique, il peut être difficile de justifier de changer la façon dont les choses sont faites, et potentiellement de changer l' outillage , en particulier lorsque les anciens et les nouveaux tests devront continuer à coexister pendant la durée de vie du projet - et vous ne voudriez certainement pas avoir besoin de réécrire chaque test que vous avez jamais créé. Ce qui est étrange, c'est que parfois, les gens pensent que c'est la seule façon d'adopter une nouvelle méthodologie de test, ce qui en soi rend plus difficile pour ces personnes d'accepter un changement sensible pour le mieux.

Vraiment, la seule façon pour que quelque chose devienne réflexif est de vous forcer à le faire encore et encore jusqu'à ce que vous ne vous aperceviez plus que vous avez besoin de trop vous concentrer sur la façon de le faire. Parfois, la seule façon de le faire dans une équipe est de définir des politiques qui peuvent sembler un peu draconiennes, et de pratiquer la programmation par paires et les révisions de code, et tout ce qui peut aider les membres de l'équipe à se soutenir mutuellement et forcer littéralement le changement dans le comportement à se produire. Cependant, pour qu'une telle stratégie soit vraiment réussie, elle nécessite toujours un engagement ferme et honnête de la part de chaque membre individuel de l'équipe d'accepter ces mesures si nécessaire et de participer au processus ... et beaucoup de patience de la part de toutes les personnes impliquées. .

Aucun de nous ne se sent vraiment mal quand il n'écrit pas des tests unitaires en même temps que le code réel

Vous ne savez pas ce que vous entendez par "en même temps", mais que diriez-vous de les écrire avant le code réel?

D'un point de vue psychologique, il est facilement compréhensible que tout être humain ne veuille pas prendre la peine d'écrire des tests unitaires après le code. À ce stade, le code fonctionne déjà, alors pourquoi diable devrions-nous le tester? Une sorte de paresse se produit automatiquement parce que c'est fastidieux, apparemment inutile et ne pas écrire de tests ne semble pas être dangereux. En conséquence, je ne connais pas beaucoup d'équipes qui ont poursuivi une approche de test après une longue période.

D'après mon expérience, le test d'abord (style TDD) est quelque chose auquel vous pouvez rapidement devenir accro car il y a au moins 2 avantages immédiats, tangibles et libérant de l'endorphine:

• Il vous aide à concevoir votre code face à face avec des exigences exécutables concrètes et à améliorer la conception au fur et à mesure que vous refactorisez, ce qui est beaucoup plus utile et gratifiant que de simplement vérifier une chose qui fonctionne déjà.

• Le cycle TDD est ponctué de fréquents moments de «barre verte» où vous pourrez savourer le goût du succès immédiat. Il garde constamment votre esprit satisfait et prêt à utiliser la prochaine fonctionnalité à implémenter.

Je n'essaierais donc pas de faire en sorte que votre équipe se sente mal lorsqu'elle n'a pas passé les tests. Au lieu de cela, j'essayerais de les faire se sentir bien comme ils le font. TDD est une façon de le faire.

vous devez d'abord vous assurer que l'écriture d'un test et son exécution sont faciles, obtenir le cadre mis en place dans les projets en cours et rendre cette procédure de configuration simple à inclure dans les projets futurs

de cette façon, quand un programmeur veut tester une nouvelle fonctionnalité qu'il essaie de déboguer, il n'a pas besoin de passer par une douzaine de cerceaux pour que les tests fonctionnent correctement

plus quelque chose de maladroit est à faire, moins il est probable que vous en fassiez une habitude

Une des choses que j'ai faites et qui a quelque peu réussi à provoquer un changement de culture est de mettre en place un séminaire hebdomadaire de «curation de tests unitaires». Le but officiel de cela est d'aider à maintenir la suite de tests unitaires rapide et à jour, mais le but le plus important, à mon avis, est de donner aux gens un moyen à faible pression de se présenter, de poser des questions et de s'exercer à tester . Le fait que vous soyez prêt à consacrer une heure ou autre par semaine exclusivement aux tests envoie également le message que c'est important.

Je pense que vous obtenez un peu de changement de culture de cette façon et que vous commencez à supprimer l'obstacle à le faire "par réflexe", comme vous le dites. Les gens auront tendance à revenir à leurs vieilles habitudes au premier signe d'adversité - avoir une réunion comme celle-ci ne résoudra pas cela d'un seul coup, mais je pense que cela initiera un changement de culture et supprimera la barrière qui résulte de pas vraiment sachant ce que vous faites.

Avoir un groupe de programmeurs dans lequel tous veulent naturellement faire quelque chose est une utopie (surtout quand on parle d'un grand groupe).

Les tests unitaires et d'intégration sont des normes . Vous créez une norme pour un flux de travail et chaque membre de l'équipe doit la respecter. Les normes doivent être élaborées avec l'aide de professionnels de l'AQ, car ils le savent mieux. Un programmeur doit respecter les normes. Ce que vous pouvez faire, c'est rendre les normes propres, faciles à comprendre et à suivre.

Il ne s'agit pas de faire confiance à votre propre code et de vouloir l'utiliser, il s'agit d'avoir besoin d'avoir des normes de codage et de test que tout le monde utilise pour faire de bonnes choses, et tout programmeur devrait le comprendre.

Lorsque vous incitez les gens dès le départ à suivre la norme, cela devient un réflexe et il sera suivi. En faire une règle selon laquelle aucun code ne peut être mis dans la base de code sans un test unitaire convaincrait les gens qu'ils doivent le faire. Pour les référentiels de projets, il existe des règles encore plus restrictives. Par exemple, les entreprises font des tests unitaires avant de réellement coder l'unité (quand elles font la spécification du module) et c'est une très bonne méthode. Si un programmeur met du code dans le projet / base de code, le code est exécuté à travers le module de test et si les tests unitaires ne réussissent pas, ils retournent au travail.

S'il est difficile pour le moment d'ajouter des normes et des règles, pensez au moins à les ajouter dans de futurs projets.