Comment motiver les collègues à écrire des tests unitaires? [fermé]

92

Nous travaillons sur un grand produit en production depuis environ 5 ans. La base de code est .. euh .. fonctionne. Pas vraiment bien mais ça marche. Les nouvelles fonctionnalités sont mises en production et testées avec un petit contrôle qualité. Les bugs sont corrigés, etc. Mais personne, sauf moi, n'écrit des tests unitaires. Personne n'utilise le pouvoir de "traquer" les bogues en écrivant des tests unitaires pour s'assurer que ce bogue spécial (cas de test) ne se reproduira plus jamais.

J'ai parlé à la direction. J'ai parlé à des développeurs. J'ai parlé à tous les membres de l'entreprise. Tout le monde dit: "Oui, nous devons écrire plus de tests unitaires!" C'était il y a environ un an. Depuis lors, j'ai forcé l'introduction de la révision du code pré-engagement ( Gerrit ) et de l'intégration continue ( Jenkins ).

J'ai organisé des réunions sur les tests unitaires et j'ai également montré les avantages de l'écriture de tests unitaires. Mais personne ne semble être intéressé.

Q1: Comment motiver mes collègues à écrire des tests unitaires?

Q2: Comment rester motivé pour suivre mes normes de qualité de code personnelles? (Parfois c'est vraiment frustrant!)

PS: Quelques faits frustrants (atteints en 1 an):

  • Total des tests unitaires: 1693
  • Total "exemples de tests unitaires": environ 50
  • Fait par moi: 1521

Edit: Est-ce que j'attends trop? C'est mon premier lieu de travail et j'essaie de faire de mon mieux.

Edit 2: Sur la base de toutes les réponses, j'ai créé une petite liste de contrôle pour moi-même. J'ai parlé à deux développeurs en privé et nous avons eu une conversation bonne et honnête.

L'un d'entre eux m'a dit, comme Telastyn , qu'il était vraiment mal à l'aise avec les tests unitaires. Il a dit qu'il aimerait être "plus professionnel" mais qu'il a besoin d'un coup de pouce. Il a également déclaré que notre réunion de test unitaire avec tous les développeurs (autour de 9-11) était bonne, mais trop encombrante. Meh Certains critiques pour moi, mais je vais apprendre de cela. (Voir les réponses ci-dessous concernant les réunions de tdd kata!)

L'autre a déclaré qu'il n'était pas intéressé par l'écriture de tests unitaires. Il pense que son travail est suffisant pour son salaire. Il ne veut pas faire plus d'effort. J'étais presque sans voix. Typique 9-5 "travailleur".

La semaine prochaine, je vais parler aux autres développeurs.

Merci pour vos bonnes réponses (jusqu'à présent!) Et votre soutien. J'apprécie vraiment cela! J'ai beaucoup appris, merci beaucoup!

lurkerbelow
la source
Est-ce que les 172 autres tests unitaires que vous avez effectués au cours des années précédentes ou quelqu'un d'autre fait-il des tests unitaires pour lesquels vous minimisez leur contribution?
JB King
16
Ces 172 autres tests unitaires ont été effectués par un développeur qui a quitté l'entreprise. triste :(
lurkerbelow
6
S'il vous plaît continuez à parler des chiffres. Combien de bogues ont été découverts au cours de la dernière année, combien ont été découverts et combien ont été évités par les tests unitaires. Combien de temps passons-nous à écrire des tests (1521 par an par une personne) par rapport à "Faire du vrai travail" (selon ce que vos collègues de travail pensent probablement). Est-ce qu'ils perçoivent l'UT comme bénéfique ou comme une perte de temps? Montrez-moi l'argent.
mattnz
1
Par curiosité, vos collègues ont-ils une stratégie de débogage alternative? TDD est utile pour prouver que quelque chose fonctionne comme prévu, mais pas autant pour les problèmes inconnus. Ils peuvent être à l'aise de simplement accrocher un débogueur.
Spencer Rathbun le
3
Accrocher un débogueur à des fins de test est correct, mais cela ne garantit pas que le code fonctionnerait dans quelques jours / semaines / mois et c'est le vrai problème.
lurkerbelow

Réponses:

48

J'ai remarqué que parler de TDD fonctionnait à peine. Les gens aiment voir des résultats bruts . Dire que "passer des tests réduira le temps de développement" est probablement vrai, mais cela ne suffira peut-être pas à convaincre quiconque.

J'étais dans une position similaire (enfin, pas aussi mauvaise que la vôtre), et cela s'est en quelque sorte résolu lorsque les gens ont commencé à travailler sur mon code (note: mon code a été testé à l'unité, d'autres pas beaucoup). Quand quelque chose a cessé de fonctionner, un suivi naturel après une enquête locale a été de me demander quelle pouvait en être la raison . Puis nous nous sommes assis, nous avons fait des tests unitaires et avons vu ce qui s’est passé. Si les tests réussissaient, la plupart du temps, les problèmes étaient liés au nouveau code non testé. Sinon, les tests ont généralement permis de déceler le problème (ou du moins de nous orienter dans la bonne direction). Nous avons corrigé le bogue, les tests remontaient, tout le monde était content.

Pour résumer, quelques situations comme celle-ci se sont produites et 2 autres développeurs sont devenus des passionnés de TDD / tests (il en reste encore quelques-uns à faire, mais cela semble prometteur).

Pour ce qui est des conseils, vous pouvez essayer le kata TDD; tâche simple à mettre en œuvre en utilisant une approche d'abord test plutôt que sans test . En fonction de la complexité de la tâche, l'approche non-test devrait généralement être plus lente, en particulier avec les modifications incrémentielles requises:

Modifier : Commentaire de l' OP m'a fait prendre conscience qu'il ya l' argument encore plus fort à sa disposition - régression aka les bugs de retour . Ces types de situations sont des exemples parfaits démontrant à quel point les tests unitaires peuvent être bénéfiques. Les gens aiment les chiffres - comme je l'ai dit, dire "le test unitaire, c'est bien" n'est peut-être pas convaincant, mais organiser des données comme ci-dessous pourrait sûrement être:

  • temps passé à implémenter la fonctionnalité (aucun test n'a été écrit; je suppose que cela s'est passé souvent, il devrait donc être relativement facile de trouver un tel exemple)
  • temps estimé pour implémenter une fonctionnalité avec TDD (ou même des tests après approche; peu importe - ce qui est important, c'est la présence de tests unitaires)
  • temps passé à résoudre le bogue entre le code non testé et le code testé

Une chose à propos de laquelle vous devez vous mettre en garde (cette hypothèse est évidente mais vaut la peine d'être notée): biais de résultat - assurez-vous de ne pas sélectionner un exemple où le seul moyen de détecter un bogue avec test était d'écrire test pour ce bogue. D'habitude, personne ne sait qu'un bogue se produira immédiatement, mais il est tentant de dire "ce bogue serait trivial si nous avions un test pour X" - il est facile de trouver une tactique gagnante pour une guerre après qu'elle soit terminée.

Le résultat de ces exemples devrait être une simple question: si vous pouviez passer x-heures à développer la fonctionnalité Y, pourquoi insisteriez-vous à le faire en 2x ?

jimmy_keen
la source
Merci pour votre contribution. Je pense que je vais planifier une réunion TDD avec les katas. Deux développeurs par réunion afin que je puisse vous aider. Oui, le logiciel "fonctionne". Mais beaucoup de bugs "retournent". Si quelqu'un corrige quelque chose dans le module A, le sous-module A1 ne fonctionnera peut-être plus dans certains cas. La plupart du temps, ces bugs ne sont pas détectés lors de l'assurance qualité. C'est une perte de temps. Ecrire des tests unitaires: (peut-être) 1h. Obtenir un rapport de bogue de la part du client, analyser, planifier, réparer, réviser le code, compiler, livrer le correctif, etc. à propos de ... 6-8h.
lurkerbelow
L'image vaut 1000 mots et tout. Il est plus convaincant de montrer que cela fait gagner du temps que de dire que cela devrait gagner du temps .
R0MANARMY
4
@lurkerbelow: l'argument des erreurs renvoyées (ou de la régression si vous le souhaitez) est très puissant. Pensez à arranger le problème ou le bogue existant que vous avez passé trop de temps dans ces exemples et montrez comment la rédaction de tests aurait pu aider.
km
10
D'après mon expérience, écrire des tests ne réduit pas le temps de développement, du moins pas au début; ça augmente. Il produit toutefois un logiciel plus fiable, mieux conçu et plus facilement maintenable.
Robert Harvey
@RobertHarvey: vous avez raison, le "développement" est un mauvais choix de libellé de mon côté. Je n'ai rien trouvé de mieux pour décrire le processus de conception, de mise en œuvre, de publication et de maintenance d' un logiciel. UT à plus long terme, raccourcissez / simplifiez ce processus et c’est ce que je pensais.
km
28

Vous devez d’abord savoir pourquoi ils n’écrivent pas de tests.

Les calendriers de développement serrés en sont souvent la raison, mais vous dites que vous n'en avez pas.

La raison suivante est qu'avec une grande base de code non testée existante, écrire des tests semble probablement une tâche écrasante - un travail sans fin (comme la lessive et à peu près aussi excitant). Donc, la nature humaine est de penser que c'est trop à faire face, alors je vais le sauter.

Une autre raison pourrait être que, même s'ils pensent que les tests sont une bonne idée, ils ne savent pas trop comment commencer à les écrire, surtout s'ils n'ont jamais travaillé où que ce soit.

Une autre possibilité réside dans le fait qu’ils ne voient vraiment aucune valeur pour davantage de travail, même s’ils accordent une grande importance à cette idée.

Alors, comment gérez-vous les différentes raisons?

La première raison étant simple, montrez-leur un exemple illustrant comment cela permet de gagner du temps de développement.

Deuxième raison - montrez-leur combien de tests vous avez écrits dans une année et quel pourcentage de la base de code est couverte. Faites le calcul pour montrer combien d'autres tests ils pourraient avoir à cette époque l'année prochaine s'ils le font. Une fois que les progrès quotidiens s’accroissent, l’idée n’est pas si irrésistible. Si vous pouvez extraire les données du système, montrez-leur combien de bogues étaient des bogues répétés dans les parties non testées du code et combien de bogues répétés apparaissent dans le code avec les tests unitaires.

La raison 3 est la formation, pas seulement montrer. Faites-leur écrire des tests dans un cours de formation.

Raison 4, c'est le noeud de la question. Premièrement, choisissez un point douloureux, un de ces bugs qui est revenu plusieurs fois. Le moment venu, le moment est venu de suggérer à la direction que, si des tests unitaires étaient appliqués à cet élément, ils ne reviendraient pas comme un sou.

Une autre façon de traiter la raison 4 consiste à faire en sorte que la direction en fasse partie intégrante et que le code ne passe pas la révision du code à moins que les tests ne la passent également. Le mieux est de les approcher pour en faire une politique juste après l’un de ces points douloureux ou de préférence juste après plusieurs jours.

Nous aimons tous penser que, en tant que développeurs, nous gérons nous-mêmes (LOL), mais les plus ambitieux s’intéresseront à ce que la direction leur tient à cœur et aux professionnels qui la gèrent réellement et qui écrivent déjà les tests. S'ils ne se soucient pas non plus d'être professionnels et d'appliquer les meilleures pratiques car ils améliorent le produit, ou plutôt de convaincre les gestionnaires de ne pas être licenciés (ou de ne pas être licenciés), alors vous pourriez vous demander si c'est le bon endroit pour vous. Si vous ne pouvez pas amener la direction à se préoccuper des meilleures pratiques, vous devrez alors mener une bataille difficile et une fois encore, vous pourrez évaluer si cette culture d'entreprise convient à votre situation. Bien que chaque lieu de travail ait ses problèmes (et fuguer n'est pas toujours la solution), cet endroit ne semble pas correspondre à votre niveau de professionnalisme.

HLGEM
la source
9

Je commencerais par démontrer les avantages du TDD. Essayez de mettre en valeur les avantages des tests unitaires.

En tant qu'êtres humains normaux, les développeurs sont motivés par des avantages. Ils ne veulent pas faire des choses qui créent plus de travail. Le test unitaire signifie moins de travail . Cela signifie sortir plus avec des amis. Cela signifie avoir plus de plaisir parce que vous ne devez pas passer chaque nuit à coder jusqu'à 23 heures. Cela signifie que vous partez en vacances plus tranquillement.

L'un des principaux avantages de TDD est que vous pouvez modifier votre programme pour en faire une meilleure conception ou simplement changer le nom de quelque chose ... et tant que cette conception ne rompt pas les tests, vous pouvez être sûr à 100% que vos modifications n'a rien casser.

Un autre cas intéressant pour TDD est la création de tests unitaires pour le code hérité . Cela représenterait l’un des meilleurs moyens de commencer à refondre le mal. À long terme, cela servira à améliorer votre connaissance de la base de code, à comprendre ses forces et ses faiblesses, à repérer la logique métier codée en dur dans le code et à vous donner un bon départ pour améliorer la qualité à l'avenir!

Bonnes références pour des lectures complémentaires:

ElYusubov
la source
3
@lurkerbelow, ok, et maintenant votre prochaine tâche consiste à surveiller ces erreurs pour détecter les bogues. Surveillez votre traqueur de bogues et les modifications de code qui surviennent. S'il n'y a pas de bugs, alors votre collègue a un point. S'il y a des charges, alors vous avez un point. De toute façon, vous aurez des preuves empiriques.
gbjbaanb
3
Le fait que vous puissiez prouver que vos modifications ne vous ont pas cassé autre chose est un gros pouvoir à mes yeux. La réponse immédiate du logiciel en fonctionnement est également utile. Malheureusement, certaines personnes ne voudront jamais tenter l'apprentissage au démarrage. Ironiquement, ce démarrage limité pour une gratification immédiate est trop dans notre culture de la gratification immédiate ....
Jennifer S
7

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

Je pense avoir mis ce lien en signet dans un article de Jeff Atwood il y a quelque temps [edit: ouais, le voici] . Vieux mais pertinent. En raison de ces avantages et d’autres qui seront sans aucun doute décrits dans d’autres réponses, vos programmeurs devraient être capables de se motiver ! Cela leur permettra de travailler plus efficacement et ainsi de faciliter leur travail. Qui ne veut pas ça?

En ce qui concerne votre deuxième question: votre sens de la propriété et votre fierté vis-à-vis des normes de qualité de votre code devraient vous faire avancer . Pensez à ce que vous voulez accomplir en appliquant de telles normes et à qui en profite. Mes normes de code personnelles peuvent également être frustrantes, mais je me sens toujours comme si je rendais service au monde / à la société / à l’équipe en les appliquant. Donc, je ne pense pas que vous essayez de faire trop - les résultats varieront d’un endroit à l’autre mais au moins vous faites l’effort.

gws2
la source
7

Cela semble être une grosse affaire de exemple .

Vous combattez deux aspects inhérents à la nature humaine:

  • Les créatifs n'aiment pas les processus.
  • La plupart des gens n'aiment pas les jugements négatifs externes sur leur qualité.

Il est très difficile de lutter contre cela avec des conférences, des déclarations de gestion, voire de la logique. Vous devez gagner en profitant d'un aspect alternatif de la nature humaine.

  • Les gens imitent le comportement des meilleurs employés

Si les meilleurs employés utilisent TDD et que cela fonctionne, le processus prendra de l'ampleur. Si ce n'est pas le cas, ce ne sera pas le cas. Si vous avez besoin de convaincre quelqu'un, c'est le premier ou le plus important des 2 employés.

MathAttack
la source
Il est à noter que, sans être déjà dans une culture qui embrasse le TDD, vos collègues ne vous poussent pas à progresser. S'ils voient une faiblesse dans votre méthode, ils l'appelleront en disant "pour que ça ne marche jamais". Pour donner l'exemple, vous devez investir votre temps et vos efforts pour améliorer votre méthodologie.
perfectionniste le
3

Leur demander.

Vous dites que les gens ont été informés et acceptez qu'ils devraient écrire plus de tests. Pourquoi ne sont-ils pas?

Ce n'est peut-être pas (souvent le cas n'est pas) une question de motivation simple. Ils pourraient les oublier. Ils pourraient se sentir sous la pression du temps. Ils pourraient ne pas savoir écrire de bons tests. Ils pourraient penser que vous êtes si bon qu'ils n'ont pas besoin de le faire. Connaître la cause fondamentale vous aidera à mieux résoudre le problème.

Telastyn
la source
6
En théorie, c'est une bonne idée, mais il est difficile de répondre à la question. Donc, si vous savez que les tests unitaires sont bons, pourquoi ne les utilisez-vous pas? sans ressembler à un abruti, par exemple, je ne sais pas comment ou je n'ai pas le temps ou je suis intelligent, mon code devrait fonctionner . Cette situation rendrait normalement les gens sur la défensive et donnerait de mauvais résultats.
R0MANARMY
2
Je ne veux pas parler des "erreurs" des autres peuples. Peut-être devrais-je bavarder en privé, par exemple prendre une bière ou dix. La pression du temps n'est pas vraiment un point. Nous avons un excellent calendrier avec suffisamment de temps tampon. (150% + estimation)
lurkerbelow
2

Vous penseriez que les tests unitaires seraient la vente eux-mêmes. Je ne sais pas comment votre entreprise fonctionne, mais lorsqu'il y a un problème lors d'un déploiement de production, nous le résolvons jusqu'à ce qu'il soit résolu. Peu importe si cela se produit à 2 heures du matin le dimanche matin. C'est très rare pour nous, mais quand c'est le cas, ça craint.

Je commencerais par leur demander combien de fois ils devaient se lever au milieu de la nuit pour résoudre un problème majeur qui aurait facilement pu être résolu en test automatisé. Cela ne veut pas dire que les tests automatisés vont tout régler, mais cela devrait aider à réduire cela.

Le deuxième grand vendeur est le cycle d'assurance qualité. Avant le démarrage de TDD dans mon entreprise, nous soumettions les nouvelles versions à l'assurance qualité afin de les tester chaque semaine. Ils créeraient une pile de bogues à partir de cette version, nous les corrigerions et en publierions une autre. Répétez jusqu'à la fin. Le premier projet que nous avons mené à TDD n’a nécessité d’expulsion à l’Assurance qualité que plusieurs semaines plus tard. Et le nombre de bugs trouvés a été très, très petit. 10% par rapport à un projet similaire. Avez-vous besoin de compiler ces statistiques pour votre équipe?

L’autre grand argument de vente était la manière dont le code s’appliquait après l’adoption de TDD. C’était plus facile à lire car nous voulions faciliter les tests. Affiche une comparaison entre le code écrit pour les tests unitaires et le code non écrit.

Enfin, montrez-leur comment ils pourront refactoriser le code en toute confiance.

Gardez tout cela à l'esprit lorsque vous n'avez pas envie de passer des tests. :)

bwalk2895
la source
1

J'aimerais développer la réponse de HLGEM , en particulier cette section:

La raison suivante est qu'avec une grande base de code non testée existante, écrire des tests semble probablement une tâche écrasante - un travail sans fin (comme la lessive et à peu près aussi excitant). Donc, la nature humaine est de penser que c'est trop à faire face, alors je vais le sauter.

J'ai constaté que le code que j'écris dans le but d'écrire des tests est nettement meilleur que le code que j'écris sans l'intention d'écrire des tests; me demander comment vais-je tester cette fonction? oblige à une meilleure conception de chaque fonction. (Moins de confiance dans les données globales ou semi-globales; les entrées / sorties séparées du calcul, les fonctions ne font qu'une chose, le traitement cohérent des erreurs, etc.)

Essayer de mettre des tests sur du vieux code qui n’a pas été écrit pour les tests peut être frustrant.

sarnold
la source
1

J'ai utilisé quelques techniques:

a) mettre en place une construction automatisée. Quand quelqu'un casse quelque chose que vous avez testé, montrez-lui comment le test l'a détecté et à quel point le bogue aurait été grave.

b) Faites des projets complexes avec des tests (vous conduisez). Cela montrera combien peu de bugs existent dans ce projet. J'ai eu un projet d'interaction serveur complexe qui a commencé à fonctionner parfaitement. L'assurance qualité n'a jamais échoué et tous les tests d'intégration se sont déroulés sans heurts. Ce système a été qualifié de très stable et la direction générale en était satisfait. Ce que vous faites dans ces situations est de montrer comment les tests unitaires ont permis cela.

c) Attirez une personne à la fois. Celui qui vous écoute. Luttez contre les bugs et montrez comment les tests révèlent des problèmes profonds et difficiles CA aide. Ce n'est jamais une chose facile. Mais une fois que vous aurez un fan, il ne fera qu’aider. C'est un effet domino.

utilisateur84575
la source
c) semble bon pour mon cas
Nakilon
0

Cuire les tests unitaires dans le processus. Si un bogue dans la production est trop évident pour être détecté dans un test unitaire, alors ce gars-là prend la responsabilité. Désignez des personnes pour écrire chaque test qu’elles réalisent. Choisissez au hasard des cas et surveillez l'exécution de quelques cas chaque semaine. En effectuant des tests unitaires, les gens poseront des questions sur les exigences et les lieront éventuellement au développement et développeront, espérons-le, un logiciel à la fois nécessaire et fonctionnel :)

Aucune chance
la source
Merci pour votre contribution. Vous avez déclaré que l'écriture de tests unitaires oblige le développeur à réfléchir un peu plus sur les exigences, etc. Cela pose parfois un problème. La fonctionnalité A est implémentée et fonctionne. QA indique à dev que le scénario de test x ne fonctionne pas car il n'a pas envisagé les éventuels effets secondaires. Nous utilisons l'intégration continue pour appliquer nos tests unitaires. Tous les tests sont exécutés si quelqu'un vérifie quelque chose. Nous allons donc détecter les éventuels effets secondaires avant d'expédier à l'AQ / aux clients.
lurkerbelow
1
Le test unitaire est différent du test d'intégration. Je pense que le développeur est également responsable des tests d'intégration et que le rôle de l'assurance de la qualité est de s'assurer que tout est en ordre (dans la mesure de la vérification qu'il peut effectuer). Bien sûr, il pourrait y avoir des problèmes de versions, des éléments manquants, la distribution de code sur des serveurs, etc. qui ne peuvent pas être détectés à l’avance, mais ils n’ont rien à voir avec les exigences ou les tests unitaires.
NoChance