Je leur ai naturellement proposé une journée "Tests unitaires et TDD", formule déjà éprouvée chez d'autres clients, avec un programme progressif :
- Présentation théorique (2h) : coût de correction des bugs, pourquoi tester, tests unitaires, mocks, TDD, bonnes et mauvaises pratiques, conseils et pièges, lien avec l'agilité, intégration continue, etc ...
- Démonstrations sous forme de Kata (1h30) : exemple basique, exemple simple, introduction aux mocks avec Mockito, ...
- Et l'après-midi, mise en pratique pour les participants sous forme de coding-dojo Randori (3h30) : tests simples avec JUnit, puis sujet propice à la mise en oeuvre des mocks, cette session me permettant de guider les participants, les accompagner, d'insister sur les bonnes et mauvaises pratiques, tout en leur offrant un espaces d'expérimentation où ils peuvent toucher du doigt les tests unitaires en approche TDD
- Conclusion, rétrospective, ROTI
Les retours en fin de journée étaient très positifs, d'ailleurs le ROTI était presque de 5/5 (à quelques "4" près), que du bonheur ! Mais il faut dire que les participants s'étaient avérés ouverts d'esprit, et curieux d'en savoir plus sur ce monde qui leur était quasiment totalement inconnu.
Merci à eux pour leur participation, leur implication, la bonne humeur, et la bonne ambiance. Et merci également aux visiteurs d'un moment qui sont venus partager et échanger avec nous.
Néanmoins, dans les nombreux échanges au cours de la journée, le scepticisme s'est manifesté à plusieurs reprises, surtout que sans aucun tests unitaires, et encore moins automatisés, cette équipe produit jour après jour, un logiciel apparemment de qualité, quasiment sans bugs en production.
Et je dois reconnaître avoir eu la sensation d'atteindre ma limite en matière de persuasion sur les apports et les gains que peuvent apporter les tests unitaires en TDD. Certes, les participants ont exprimé leur intérêt pour cette approche, leur croyance en ma "bonne" parole, mais le scepticisme persistant m'a quelque peu frustré, je dois l'avouer.
Je suis convaincu dans l'intérêt des tests unitaires, à bon escient, au-delà de limiter les bugs, mais comment partager cette croyance ? Comment communiquer autour des déclics successifs que j'ai pu avoir ces dernières années, après des heures de pratiques, de difficultés, d'échecs, de succès ? La formule que je propose sur une journée, avec ses phases progressives et complémentaires, donne satisfaction, les retours en attestent. Mais comment faire mieux, comment aller plus loin, pour déclencher pourquoi pas un engouement, une euphorie pour cette pratique, certes nouvelle et déconcertante, mais tellement bénéfique ? Je m'interroge .....
Et toi, lecteur de passage ici ? Quelle vision as-tu des tests unitaires ? Du TDD ? As-tu testé voir adopté ces pratiques ? Qu'est-ce qui t'a fait basculer du côté lumineux de la force ? Comment partages-tu ton engouement ? Quelles difficultés rencontres-tu ? Quelles solutions as-tu testé et adopté pour prêcher, autour de toi, la bonne parole, la bonne pratique ?
L’intérêt du TDD que vous avez communiqué c'est tout simplement de limiter les bugs?
RépondreSupprimerMoi je ne vois pas TDD comme simplement limiter les bugs mais aussi apprendre et créer une bonne design avec refactoring.
Alors si limiter les bugs ne suffise pas peut être que la rapidité de construction fera l'affaire?
Merci pour votre commentaire.
RépondreSupprimerBien sûr que nous avons beaucoup évoqué tous les autres apports des tests unitaires et du TDD, "au-delà de limiter les bugs" comme je disais dans l'article : transcription des critères d'acceptation fonctionnelle en tests techniques, aide au design et à une conception testable, rapidité de développement, sérénité, etc ...
Il est vrai que ces aspects ne ressortent pas bien dans mon article, trop l'accent sur l'aspect "bug", mais c'est ce qui est le plus ressorti lors des discussions : intéressant !
Merci
Salut Xavier,
RépondreSupprimerSi les développeurs savent produire un logiciel de très bonne qualité (sans bug, maintenable, évolutif, compréhensible...) et qu'ils sont content de leurs pratiques, pourquoi changeraient-ils ? Ils devraient partager leur potion magique ;-)
De mon côté, plus je fais de TDD plus j'ai du mal à m'en passer. Pour moi, je fais du TDD pour :
1. écrire la spec (et non un test) de ce qui est attendu ;
2. avoir un retour très rapide que mon code est correcte. Comment tester rapidement que les 4e étape d'un workflow est correct ? Comment s'assurer du bon comportement de mon code si j'ai une FaultException d'un WebService... ;
3. m'aider à mieux concevoir mon code (Single Responsability...) ;
4. avoir une base de tests de régression (rapide à exécuter) pour faire du refactoring ;
5. travailler de façon incrémentale ;
6. avoir un code testable.
La plupart des personnes (même si elles ne font pas de TDD) adhèrent à cela. La difficulté est la pratique qui n'est pas facile à acquérir et qui demande un ré-apprentissage de sa manière de développer et de penser.
Salut Rémi,
SupprimerMerci pour ta réaction.
L'équipe n'a pas de "potion magique", mais juste un cadre actuel de travail, une architecture et des habitudes qui font que leur production se passe bien. Ils sont essentiellement sur un produit existant qu'ils corrigent ou font évoluer. C'est intéressant de voir comment ils arrivent à ce résultat sommes toutes assez positif.
Pour ce qui est des avantages du TDD, tu me connais, je ne les ai pas listé, tu l'as fait à ma place, et je suis totalement en phase.
Comme tu le dis, la grosse difficulté, c'est la pratique et surtout le changement d'approche et d'état d'esprit. Lors de ces formations et accompagnements, je mesure à quel point c'est déroutant pour des développeurs qui ne sont pas du tout dans cette approche. Et c'est probablement les inquiétudes et questionnements liés à ces changements qui font émerger le "scepticisme" dont je parlais ...
Bonjour,
RépondreSupprimerJe rejoins les arguments de sanlaville mais pour répondre plus précisément à ton interrogation, Xavier, je crois qu'il est difficile de susciter l'engouement pour le TDD dont l'apport s'apprécie aussi beaucoup sur la durée.
Car c'est aussi lorsque les tests unitaires qui bordent un code s'allument en rouge, alors qu'on pensait apporter une modification maîtrisée, qu'on s'aperçoit des effets de bord mis en avant et pas si maîtrisés que ça. Et ce n'est qu'une fois une telle expérience vécue en situation réelle que la sérénité prend véritablement place.
Si de bons développeurs réussissent à éviter les bugs sans TDD (ce qui résiste AMHA rarement à une analyse objective si on parle d'un soft d'une taille conséquente), ils deviendront encore meilleurs et plus rapides avec le TDD.
Il y a une vraie difficulté à changer sa façon de faire, à passer de l'affirmation "notre code n'est pas assez découplé pour pouvoir y introduire des tests unitaires" à "les tests unitaires sont notre premier levier pour atteindre une architecture plus limpide". Globalement, les développeurs qui ont vraiment goûté au TDD sont les premiers à en vanter les mérites au sein d'une équipe et l'expérience commune permet souvent à la sauce de prendre efficacement.
La frustration qui transparaît dans ton post me paraît relativement inévitable : en tant que facilitateur, tu fais mettre le pied à l'étrier et peux susciter des vocations mais pour voir évoluer des cavaliers confirmés, il faut poursuivre l'accompagnement et s'armer de patience.
Merci Laurent pour ton commentaire.
SupprimerTu as raison, ce ne sont pas les premiers tests unitaires qui permettent d'en mesurer l'intérêt, mais plutôt le jour où ils cassent au moment inattendu, ou encore, le jour où le développeur se dit "ah ben, ça y est, j'ai fini ma classe, rien d'autre à vérifier, pas besoin de relire 3 fois mon code, je suis sûr de ce que je viens de faire" !
Lors de ces journées, j'évoque ces "déclics" que j'ai eu, mais également mes difficultés, mes déboires, etc ... Mon objectif est de mettre correctement le pied à l'étrier, pour que l'équipe parte dans la bonne voie, fasse ses propres erreurs, mais évite les mauvaises routes qui peuvent amener à l'échec, au dégoût, à l'abandon ...
Mais bien sûr, comme tu le dis, il faut de la patience, de l'accompagnement, un mouvement collectif de l'équipe, et l'émergence de meneurs qui vont tirer le groupe.
Salut Xavier,
RépondreSupprimerJe comprends très bien ta frustration et je rejoins ce qui a été dit avant: il faut du temps pour apprécier le tdd. Il faut aussi beaucoup d'envie et de détermination.
Si on a un peu souffert avant, c'est encore mieux...
Enfin, je rappellerais le Driven de TDD: le tdd est bien plus que de l'automatisation des tests. Il s'agit de guider le développement.
C'est là toute sa force et ce qui le rend difficile à appréhender sans en faire l'expérience.
Puisqu'ils avaient l'air heureux, qu'est-ce qui leur a donné envie de te faire venir et mobiliser l'équipe toute une journée?
#++
Salut Benoit,
SupprimerQuel plaisir de te voir réagir ici ! :-)
Comme tu le soulignes, le TDD va guider le développement. Vers quoi ? Vers une architecture très découpée, du couplage lâche, de l'injection de dépendance, le concept "une classe = un rôle", etc ... Tous ces aspects sont nouveaux pour cette équipe qui en est très loin. J'ai mesuré à quel point l'apprentissage du TDD peut être beaucoup plus que "simplement" écrire les tests avant le code de production, il peut y avoir plusieurs défi à relever en même temps, de façon indissociable, la marche est alors assez haute ...
Pour répondre à ta question, cette équipe ne fait pas de tests unitaires, mais elle sait qu'il y a des personnes qui en font et que ces personnes en sont contentes et disent qu'il faut absolument faire comme ça. C'est donc une équipe très ouverte d'esprit qui m'a demandé de lui en parler et de l'amener dans cette direction.
Je viens de lire cela. J'ai donc pensé à ton billet.
RépondreSupprimer"The absence of bugs is completely different from the presence of quality." Nicely put by @gojkoadzic at Oredev 2011
https://twitter.com/#!/blubberplinth/status/187939321037328384
Quelques précisions suites aux réactions ci-dessus et après quelques jours de réflexions ...
RépondreSupprimerTout d'abord, j'ai peut-être publié mon article trop vite. Je l'ai fait le soir même de cette grosse journée qui a été, pour moi, très fatigante, je n'étais probablement plus vraiment objectif le soir de la publication ...
Le lendemain, nous avons à nouveau échangé avec quelques membres de l'équipe. Il en ressort que la journée les a convaincu sur les bienfaits des tests unitaires et du TDD, surtout dans certains domaines : algorithmie, communication avec des périphériques, simulations de situations particulières, base de données, etc ...
A noter également que le format de la journée a été très apprécié :
- d'abord un peu de théorie pour savoir pourquoi et comment
- ensuite une démonstration permettant de concrétiser les concepts, les outils et la méthode
- puis une mise en pratique sous forme de coding-dojo, toujours très apprécié, ludique et convivial (même si j'y ai perdu une fournée de croissants ...)
Evidemment, les développeurs ne voient pas trop comment mettre ça en pratique actuellement, sur leur code existant. Normal, ajouter du tests unitaires sur du code legacy est parmi les pratiques les plus difficiles, et nécessitant déjà une bonne maîtrise du TDD et des "bons" tests.
J'ai moi-même commencé à regarder comment remanier leur code actuel pour y insérer des TU et ça n'est pas gagné ... Normal, à nouveau !
Donc, côté mise en pratique, l'idée retenue est de mettre en place ces pratiques lors du démarrage imminent d'un nouveau très gros projet, mais pas forcément sur les projets et produits actuels, surtout vu la satisfaction actuelle qu'il n'est pas nécessaire de remettre en question.
A suivre ...
Bonjour,
RépondreSupprimerNous appliquons dans notre équipe le TDD avec les mêmes bénéfices et difficultés citées dans votre article et les commentaires.
J'ajouterai (je ne crois pas l'avoir lu) qu'il y a d'autres vertus du TDD dans une équipe:
- la "documentation" / information que l'on peut retirer des tests unitaires.
Comment fonctionne telle classe en observant ces tests unitaires ?
- Elle favorise et développe la culture du refactoring/nettoyage du code à mon sens en appliquant le principe DRY notamment. Je prend dans ce cas l'image du scout qui consiste à laisser plus propre en partant l'endroit ou il a campé. Ce principe est trop souvent négligé lorsque le TDD n'est pas appliqué.
- Le TDD peut paraitre inutile dans des équipes ou il y a des développeurs séniors et passionnés (et encore j'en doute réellement).
Maintenant, dans les faits une équipe évolue toujours, des personnes quittent l'équipe et d'autres la rejoigne. Le TDD, dans ce contexte, favorise la montée en compétence d'un nouvel arrivant en lui donnant une sécurité sur ces développement. Le TDD donne confiance au nouvel arrivant dans la mesure ou il sait si il a cassé quelque chose ou pas. Cela n'est pas négligeable pour l'intégration.
Voilà pour mon retour d'expérience sur le sujet.
Sylvain