Comment convaincre ses coéquipiers d'utiliser TDD [fermé]

Je suis la seule personne de mon équipe à utiliser TDD. Comment les faire utiliser?

Je suis ennuyé que lorsque je tire, le code de quelqu'un casse mes tests et c'est moi qui dois les corriger.

L'utilisation de github, fork et pull request résoudra-t-elle ce problème, de sorte qu'ils doivent passer le test avant que la traction ne soit acceptée?

Je ne suis pas le chef de projet et je n'arrive pas à la convaincre de l'utiliser.

De mon point de vue, la seule façon de convaincre quoi que ce soit au sujet des tests est de démontrer qu'ils sont utiles - c'est-à-dire que les échecs de test aident à trouver et à corriger les bogues .

Cependant, la façon dont vous décrivez le problème ne semble pas être le cas ici. Regardez...

... quand je tire, le code de quelqu'un va casser mes tests et c'est moi qui dois les corriger.

Si je comprends bien, vous voulez dire que vous devez modifier les tests. Eh bien, cela ne ressemble pas à des échecs de test qui aident à trouver et à corriger les bogues, n'est-ce pas? Si les tests ne permettent pas de trouver des bogues, c'est une position assez faible pour commencer à convaincre vos collègues - que pourraient-ils espérer gagner? corrections fastidieuses dans un code de test fragile?

Cela peut sembler une impasse, mais ce n'est vraiment pas le cas. Votre objectif final (convaincre pour TDD) est toujours assez logique, ne le laissez pas tomber. Concentrez simplement vos efforts sur l'élimination de l'obstacle que vous avez découvert.

Les échecs de test qui vous dérangent maintenant sont essentiellement des "fausses alertes" - ce qui signifie que ce sont des bogues dans les tests qui ne sont pas dans le code. Utilisez-les comme une opportunité d'améliorer les tests, d'apprendre à faire une bonne conception de test fiable. Travailler sur des tests pour rendre les "fausses alertes" moins fréquentes et pour faciliter la découverte de vrais bugs dans le code testé.

Lorsque vous découvrez de vrais bogues, faites-le savoir à vos collègues et aidez-les à les corriger - et n'oubliez pas de signaler que ces bogues sont détectés par vos tests. Cela constituera un terrain vraiment solide pour convaincre vos collègues.

Il convient de mentionner que les compétences en conception de tests que vous développez au stade "préliminaire" seront probablement nécessaires à nouveau si (quand :) vous finissez par convaincre vos coéquipiers d'utiliser TDD. Penses-y...

... Que se passerait-il lorsque le développement piloté par les tests serait présenté à vos collègues inexpérimentés?

La première chose à attendre est que les gars commenceront à écrire des tests de merde et (horreur!) Même à en casser de bons tout en apprenant. Pour les aider à trouver un moyen de le faire correctement, vous aurez besoin d'une solide compréhension d'une bonne conception de test.

Toutes les erreurs que vous trouvez et corrigez dans vos tests maintenant, seront répétées encore et encore par tous vos coéquipiers lorsqu'ils commenceront à apprendre. Si (quand!) Cela se produit, vous feriez mieux d'être prêt à expliquer rapidement et clairement comment vous améliorer si vous voulez qu'ils restent positifs à propos du TDD.

Quand j'ai voulu encourager l'utilisation du développement piloté par les tests, j'ai dirigé un Cyber-Dojo . Avec ce type d'exercice, l'accent n'est pas mis sur le code lui-même, mais sur le processus d'écriture du code .

Nous avons passé un après-midi, à deux, à répéter les mêmes kata, mais dans des conditions différentes. Nous avons commencé avec tous les groupes faisant un exercice en même temps. Cela a fourni une base de référence.

Nous avons ensuite discuté de certains des principes de base du TDD, fait changer de partenaire et répéter le même kata. Nous avons répété le même kata pour minimiser la génération de code et concentrer à la place les gens sur le processus de nommage des cas de test et du cycle Rouge / Vert.

Ensuite, nous avons répété le kata à nouveau, mais environ toutes les 10 minutes, une personne dans chaque groupe se déplaçait vers un autre groupe, simulant les environnements d'équipe plutôt fluides que nous nous trouvons souvent ces jours-ci.

Dans l'itération finale, nous avons eu les deux partenaires changer toutes les 10 minutes environ en groupes différents. Cela a permis de démontrer qu'avec TDD, même le transfert d'une équipe à une équipe complètement différente ne devait pas nécessairement être trop pénible, car le projet ne devrait être exécuté que sur un cycle rouge / vert.

La chose intéressante était qu'il y avait peu de gens qui avaient fait un TDD avant la session, mais ce que les connaissances TDD y ont été rapidement diffusées jusqu'à l'itération finale à travers le kata, la plupart des gens pensaient de manière TDD ou pouvaient au moins comprendre pourquoi il pourrait être bénéfique.

Les gens ont généralement dit que l'après-midi était à la fois amusant et instructif et nous examinons maintenant d'autres façons d'utiliser Cyber-Dojo sur mon lieu de travail.

Cyber-Dojo , écrit par Jon Jagger , fonctionne incroyablement bien pour ce genre d'exercice. Il est un environnement intégré basé sur le Web pour faire la pratique délibérée de TDD et d' apprentissage sur la dynamique de l' équipe. Il a beaucoup de kata sélectionnés spécifiquement pour aider les gens à se concentrer sur le processus de TDD et non sur le problème. Il prend également en charge une gamme de langages, de Python et Ruby à Java et C ++.

La meilleure chose est qu'après avoir fait un kata, vous pouvez ensuite revenir en arrière et regarder la progression rouge / verte (ou peut-être pas * 8 ') de chacun des groupes participants. C'est des feux de circulation sont une excellente façon de visualiser comment le processus fonctionne TDD.

Si vous voulez votre propre serveur CyberDojo, tout le projet peut être trouvé sur github et il y a même une machine virtuelle d'appliance Linux clé en main liée à partir de là, ce qui signifie qu'en supposant que vous avez déjà installé VMware player ou VirtualBox , vous pouvez être opérationnel dans quelques minutes de téléchargement de l'appliance!

S'ils résistent au TDD, c'est ok. Beaucoup de gens (y compris moi-même) ont d'abord des problèmes pour écrire des tests unitaires.

Cependant, vous devriez vous poser la question de ne pas avoir de tests unitaires du tout et de la rupture des tests unitaires. Les tests unitaires sont un filet de sécurité qui empêche de nombreux bogues possibles et permet la refactorisation du code. Expliquez une meilleure qualité de code et un code plus propre.

Je pense que le mieux serait de trouver une vidéo qui explique les avantages de l'utilisation de TDD et de la montrer lors d'une réunion.

Si elle refuse d'écouter, vous pouvez essayer d'aller vers quelqu'un au-dessus d'elle, mais cela pourrait ne pas être très intelligent si votre patron est si têtu.

Il est vraiment difficile de convaincre les gens de changer leurs habitudes, mais voici quelques choses que vous pouvez essayer:

• Parlez aux autres développeurs et expliquez-leur pourquoi vous pensez que TDD est une bonne idée.
• Convainquez-les (ou au moins certains d'entre eux) de l'essayer pendant un temps limité
• Essayez d'établir des exigences minimales pour bien travailler en équipe. Ils ne doivent pas nécessairement faire TDD, mais ils ne devraient certainement pas vérifier le code qui échoue aux tests unitaires. Il s'agit d'un problème distinct que de les convaincre d'utiliser TDD, et il est beaucoup plus important de le résoudre.
• Essayez de convaincre la direction d'appliquer une période d'essai pour TDD. Vous devrez être prêt à fournir des preuves de la raison pour laquelle il s'agit d'une bonne pratique et de la manière dont elle permettra à l'entreprise de gagner du temps et de l'argent à l'avenir.

Si rien de tout cela ne fonctionne, vous voudrez peut-être envisager de travailler ailleurs. Il existe de nombreuses autres entreprises qui vous faciliteraient considérablement la vie.

Il y a 2 problèmes légèrement différents ici: amener les gens à faire du TDD et les gens qui cassent vos tests.

Je ne suis pas sûr du premier numéro, personnellement je le trouve une façon de travailler artificielle et non adaptée à tous les types de développement. Je suis tout pour avoir une bonne suite de tests unitaires, mais je trouve généralement plus efficace d'écrire d'abord le code puis les tests, car pendant l'écriture du code mes idées changent toujours, et c'est aussi une perte de temps d'écrire des tests tôt (OMI).

Sur le deuxième problème, configurez le projet de sorte que les tests unitaires soient exécutés au moment de l'enregistrement, afin que les autres développeurs n'aient pas d'autre choix que de savoir qu'ils ont réussi un test.

Comme dit dans beaucoup d'autres "comment dois-je convaincre X d'utiliser la méthode / technologie Y", ma réponse est toujours la même: par exemple.

Utilisez-le et obtenez de meilleurs résultats (mesurables). Assurez-vous ensuite que les autres le remarquent.

Sur un projet existant, vous ne le faites pas. C'est la même chose que si vous apportiez des modifications à la façon dont les accolades sont placées dans le code hérité parce que vous n'aimez pas le style d'indentation.

Beaucoup de bons conseils. Et maintenant, un peu plus ...

Vous devez gagner des cœurs et des esprits (WHAM) un luddite à la fois. Oubliez de le forcer à descendre la gorge. Beaucoup de leçons d'objet sur une période de temps indéfinie (désolé). Finalement, vous atteindrez une masse critique, convainquerez la ou les bonnes personnes.

Votre enthousiasme constant et constant pour le TDD est très important dans une campagne WHAM.

Vous devez transformer les changements de test et de code en moments d'apprentissage, les leçons qui comptent pour vos codécodeurs.Rendez-le personnel. IE Se soucient-ils de la réputation de fournir un code propre supérieur à la moyenne? Se soucient-ils de la gestion qui les harcèle à propos du code qui est maintenant en retard parce que les testeurs d'intégration leur ont donné une vérification de la réalité? Jack a-t-il un désir de modifier un code difficile mais a peur des effets secondaires?

Rassemblez de bons exemples de tests réussis pour piéger les bogues induits par le codeur. Les codeurs verront la modification des tests comme un travail inutile pour un code non pertinent; ils doivent comprendre que les tests ne couvraient que leurs fesses.

Trouvez du code avec des implications globales (une méthode utilitaire simple), créez des tests, puis démontrez que les tests permettent de changer sans crainte de tremblements de terre tout au long de l'application. Et je veux aussi souligner le problème émotionnel!

Rassemblez quelques exemples simples de code de nettoyage (c'est -à- dire passés en production) et démontrez que malgré l'effort supplémentaire pour le codage de test , nous l'avons fait plus rapidement et avec une meilleure qualité.

Avertissement: TDD n'est pas un remède et ne peut pas surmonter une mauvaise conception et codage OO (mais il peut certainement l'exposer). Ne laissez pas les Luddites blâmer l'effort du code de test pour leur incompétence.

J'essaierais à nouveau de convaincre le manager. D'après ce que vous avez écrit, je ne pense pas que vous pourriez convaincre vos coéquipiers de faire du TDD derrière son dos.

Vous devez parler sa langue. Les gestionnaires ne sont généralement pas impressionnés par la technologie, mais ils comprennent le langage des affaires:

• les tests vous feront gagner du temps lors du développement, car au lieu des tests manuels (essayer de reproduire le bug localement, jouer avec la console rails ...) vous allez lancer des tests automatiquement

• test vous fera gagner beaucoup de temps lors de la maintenance de l'application, lorsque vous pourrez facilement détecter les bogues chaque fois que vous modifiez quelque chose. Expliquez que les tests nécessitent un investissement initial plus élevé, mais qu'ils seront rentables à long terme (la maintenance de bons tests est généralement rapide et facile)

• et que ferez-vous du temps supplémentaire? créer des trucs de moar et leur faire gagner de l'argent :)

Quant aux programmeurs, essayez cet argument (cela a fonctionné pour moi, en arrière): "Vous testez le code de toute façon, avec ou sans TDD. Seulement vous le faites manuellement au lieu de l'automatiser. Les développeurs intelligents automatisent autant de choses qu'ils le peuvent. "

Sur de vrais projets avec des délais, les gens veulent se concentrer sur le travail avec ce qu'ils savent. C'est juste la nature humaine. Et si vous n'aviez jamais appris le TDD, vous seriez le même qu'elle dans cette situation. Je l'ai incarné.

Pourquoi la foule de la collecte des ordures n'aime-t-elle pas, n'apprend-elle pas et ne vit-elle pas RAII? Comment pouvez-vous défendre la gestion automatique de la mémoire tout en conservant l'ancienne gestion des ressources générales telles que les fichiers, les connexions, etc.? Parce que RAII est une technologie qu'ils ne connaissent pas, ne comprennent pas et n'ont pas le temps d'utiliser lorsqu'ils ont un délai qui nécessite un travail.

Je parie que vous n'utilisez pas RAII et que vous n'êtes pas disposé à l'apprendre et à le comprendre pour votre projet actuel. Identique à votre collègue qui n'est pas disposé à apprendre et à comprendre le TDD.