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

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!

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:

• Le calculateur de cordes de Roy
• Banque OCR

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 ?

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.

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:

• Pourquoi devriez-vous écrire des tests unitaires
• Visibilité de la motivation et tests unitaires
• L'art des tests unitaires, selon Roy Osherove

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.

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.

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.

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

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.

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.

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