Discussion :

[thierryler]

Bonjour à tous,

Je vous propose un nouvel article sur les Tests en Trois Temps (3T), illustré par un cas pratique.

Synopsis : "3T" est une version simplifiée des incontournables TDD (Test Driven Development), une méthode dans laquelle on commence par écrire des tests pour aider (guider) le développement des fonctionnalités. Ce second article sur le sujet propose une illustration de "3T" en action sous forme d'un miniroman.

L'article est disponible à l'adresse suivante :
http://thierry-leriche-dessirier.dev...t-en-pratique/

A noter que cet article fait suite à un premier article dans lequel j'avais présenté 3T et qui est disponible à l'adresse suivante :
http://thierry-leriche-dessirier.dev...va/methode-3t/

Bonne lecture.
Th.

[camus3]

Je ne fait pas du tout java , mais je trouve l'article très clair et bien "romancé". Il n'y a plus qu'a se mettre aux tests unitaires en premier lieux

[Luckyluke34]

Excellent article, très pratique, très clair, beaucoup d'humour et plaisant à lire. La méthode semble intéressante et appliquée avec succès.

J'ai quand même 3 grosses réserves après l'avoir lu :

• Les reproches faits à TDD sont discutables
  
  

  c'est mieux que des vrais erreurs qui prennent du temps et que, de toutes manières, tu vas effacer dans dix minutes.

  J'imagine qu'on fait là allusion à la première étape après l'écriture d'un test en TDD qui est de constater que celui-ci ne compile pas (car le code "réel" n'a pas encore été écrit). Je ne vois pas la perte de temps qu'il y a à réaliser cette étape. Tout au plus cela va prendre 1 ou 2 secondes, le temps de compiler juste le module de test car normalement seul lui a changé. Au contraire, ça peut faire gagner du temps avec les outils modernes de refactoring permettant de générer les classes encore inexistantes mentionnées dans le test.
  
  Quant au fait que ces erreurs auront disparu dans 10 minutes, ben oui, comme dans la méthode des 3T d'ailleurs où les tests rouges apparus lors du 2è T vont disparaitre au 3è. Cela ne veut pas dire que ces erreurs étaient inutiles.
  
  Là où je vois une perte de temps, par contre, c'est dans la mise à jour et la circulation des post-it dans la méthode des 3T. L'overhead lié au workflow T1/T2/T3 entre les développeurs me parait plus coûteux que juste compiler un test. D'ailleurs que se passe-t-il si un développeur a fini un des 2 premiers T avant les autres ? Doit-il perdre son temps à les attendre ?
  
  
• 3T ne s'attaque pas à plusieurs enjeux couverts par TDD
  
  Je veux parler du design incrémental et du refactoring.
  
  

  Le principe de "3T", c'est que tout est déjà écrit et qu'il suffit de recopier

  Je pense qu'il est illusoire de croire qu'on peut prévoir tous les tests à l'avance. Certains vont forcément apparaitre en codant. C'est toute la force de TDD qui permet de faire émerger non seulement le design du code mais aussi bien souvent de nouvelles spécifications qu'on n'avait pas recensées jusque là.
  
  

  "3T" conduit naturellement à écrire du code propre, à proscrire les duplications

  Je ne suis pas d'accord à partir du moment ou il n'y a pas d'étape "refactor" dans 3T. TDD à l'inverse implémente de façon explicite et forte la règle du boy scout (laisser le code plus propre qu'il ne l'était avant) puisqu'il y a une étape de refactor obligatoire permettant comme tu le mentionnes de réduire la duplication, parmi d'autres bonnes pratiques améliorant la qualité interne du code.
  
  

  En réalité, lorsque "3T" est appliqué sur un projet, son principe premier veut que les développements soient réalisés en partant des tests, eux-mêmes écrits à partir du cahier des charges. Or il est probable que les tests écrits par l'équipe de développement soient très proches de ceux de Bernard.

  Là encore, je suis moyennement d'accord. OK, on a besoin de tests très métier qui collent à ce que tu appelles le "cahier des charges". Mais tout aussi utiles sont les tests plus techniques, sur des classes assurant la "plomberie" générale de l'application, sur la collaboration entre classes, sur des couches applicatives situées plus dans les "intestins du système". Dans les tests de Bernard, y en-a-t-il qui vérifient si le Contrôleur communique bien avec le Modèle ? Si le DAO ou le Repository situés dans la couche persistance font bien leur boulot ? Peu de chances... Alors que TDD permet d'adresser aussi ces tests.
  
  A cet égard, l'exemple de génération de mot de passe est très trompeur car c'est une classe à la fois technique et métier et donne l'impression qu'en la testant on a fait tout le boulot. Pourtant, dire que "Ce n'est qu'une recopie des spécifications" ne répond pas à la totalité du problème.
  
  
• Le Scrum évoqué dans l'article est un Scrum tronqué
  
  Ce qui m'a mis la puce à l'oreille, c'est que l'article mentionne souvent le "cahier des charges". Or dans Scrum, il n'existe pas de tel document monolithique. Les besoins sont découpés en parties plus ou moins grandes (user stories ou autres techniques), dont la priorité change au fil des sprints, qui s'affinent, etc.
  
  

  Claire (la cliente) envoie le cahier des charges de "la boutique du Chien-Copain", qu'elle vient d'écrire, à Michel (le chef de projet)

  Dans Scrum, le Product Owner fait partie de l'équipe. Il ne se contente pas de balancer un cahier des charges à cette dernière et de revenir au moment de la release pour récolter les fruits. Il est en étroite collaboration quotidienne avec les développeurs et le Scrum Master pour raffiner son besoin, répondre aux questions fonctionnelles, écouter les propositions, arbitrer... Idéalement, le Product Owner est co-localisé avec l'équipe.
  
  

  Arrivant en bout de chaine, lors de la phase de qualification, Bernard s'assure que le logiciel livré est conforme au cahier des charges

  Dans Scrum, le testeur est plutôt intégré à l'équipe et teste pendant les sprints. Cette dernière doit contenir toutes les personnes nécessaires à la production d'un incrément logiciel complet.
  
  Où est-ce que je veux en venir par rapport aux points précédents ? J'ai l'impression que le projet décrit dans l'article tombe dans cette facilité qui consiste à ne pas changer d'un iota la façon dont on travaille avec le client pour ne pas lui faire peur, et à faire porter à la seule équipe de développement le poids du "changement agile".
  Effectivement, appliquer une méthode telle que les 3T dans ce contexte peut paraitre hyper facile puisqu'on reprend le postulat de départ du cycle en V qui est que le plan d'origine (les tests dérivés du CdC) est parfait et qu'il suffit de l'appliquer.
  
  Mais gare à l'illusion de prédictibilité. Je ne dis pas que la méthode ne marche pas, elle a l'air de produire des résultats et c'est tant mieux pour les projets en question. Je suis juste dubitatif quant à sa capacité à répondre à un des enjeux majeurs soulevées par l'agilité : répondre au changement plutôt que suivre un plan.

[thierryler]

Bonjour et merci pour ces remarques.

Dans cet article, j'ai volontairement fait l'impasse sur certains éléments et simplifié d'autres. En effet, cet article est déjà très gros et je ne voulais pas entrer plus que ça dans les détails au risque de perdre les lecteurs, qui n'ont pas tous les mêmes attentes.

J'imagine qu'on fait là allusion à la première étape après l'écriture d'un test en TDD qui est de constater que celui-ci ne compile pas

Pas du tout :-p Je parle de faire échouer un test qui compile.

D'ailleurs que se passe-t-il si un développeur a fini un des 2 premiers T avant les autres ? Doit-il perdre son temps à les attendre ?

Ca ne m'est jamais arrivé de n'avoir rien à faire sur un projet. Dans le cas que tu cites, le développeur va aller piocher dans les post-it disponibles. S'il n'y a plus de post-it, c'est surement qu'on est en fin de sprint et il peut s'occuper à ce qu'il veut d'intéressant.

3T ne s'attaque pas à plusieurs enjeux couverts par TDD

C'est tout à fait exact, et assumé.

3T est une version très simplifiée des TDD. Si les équipes en ont les moyens, elles peuvent commencer par 3T puis évoluer vers un TDD complet.

Je pense qu'il est illusoire de croire qu'on peut prévoir tous les tests à l'avance. Certains vont forcément apparaitre en codant. C'est toute la force de TDD qui permet de faire émerger non seulement le design du code mais aussi bien souvent de nouvelles spécifications qu'on n'avait pas recensées jusque là.

Dans ce genre de cas, 3T dit qu'il faut faire évoluer le cahier des charges (les specs) en conséquence. Si on travaille avec des post-it, comme dans ce second article, on ajoute des nouveaux post-it qui servent de point de départ. De cette manière, tout besoin découvert en "live" est automatiquement couvert par 3T. Bon c'est un peu le chien qui se mord la queue ; j'avoue.

Le Scrum évoqué dans l'article est un Scrum tronqué

Je voudrais répondre deux choses. D'abord je ne suis pas un expert de Scrum et ce dont je parle correspond seulement à ce que j'ai constaté dans différentes équipes. Ensuite ce n'est pas un article sur Scrum donc j'ai volontairement fait hyper light. Et c'est vrai que je vais parfois un peu loin dans l'élagage.

Je suis juste dubitatif quant à sa capacité à répondre à un des enjeux majeurs soulevées par l'agilité : répondre au changement plutôt que suivre un plan.

Malheureusement, je crains que peu d'équipes savent répondre à ce genre de question. Au final, et c'est ce que j'ai pu constater chez différents clients, le chef ré intègre du V classique à la papa. Et c'est la même chose pour les TDD (encore une fois cet article n'est pas à propos de scrum).

Là je viens de faire trois missions de suite durant lesquelles le client ne savait même pas ce qu'il voulait et encore moins ce dont il avait besoin. Quant à le convier à des réunions, laissez-moi rigoler. Encore aurait-il fallu que les membres de l'équipe ne jouent pas aux fonctionnaires le matin (comme le soir) ou soient présents tout simplement. Et puis, faut bien avouer que, des fois, on préfère que le client soit absent ;-) oups...

Et en fait, ça fait des années que je me demande comment essayer de réconcilier un peu tout ça. Comment faire assez light pour laisser passer la pilule mais sans faire si light que ça ne sert à rien ?...

[Luckyluke34]

Pas du tout :-p Je parle de faire échouer un test qui compile.

Je ne comprends pas les raisonnements du genre "les équipes trouvent ça trop complexe, en particulier pour faire échouer les tests".

Faire échouer un test n'est pas une action réfléchie et ne demande pas de développement supplémentaire. Par définition, lorsqu'on a fini d'écrire un test pour lequel la fonctionnalité n'a pas encore été implémentée, le test échoue ! C'est aussi simple que ça. En TDD, on ne réfléchit pas à comment faire échouer son test puisqu'il échoue tout seul. On réfléchit à comment le faire passer le plus simplement possible.

Je pense que beaucoup de gens s'imaginent que TDD est très compliqué car ils ne l'ont jamais vu pratiquer et une simple description de la technique leur parait trop abstraite.
Pourtant, des katas existent où on peut voir en vidéo des développeurs pratiquer TDD. Ex : http://osherove.com/tdd-kata-1/ Et ça n'a rien de sorcier.

Là je viens de faire trois missions de suite durant lesquelles le client ne savait même pas ce qu'il voulait et encore moins ce dont il avait besoin. Quant à le convier à des réunions, laissez-moi rigoler. Encore aurait-il fallu que les membres de l'équipe ne jouent pas aux fonctionnaires le matin (comme le soir) ou soient présents tout simplement. Et puis, faut bien avouer que, des fois, on préfère que le client soit absent ;-) oups...

Et en fait, ça fait des années que je me demande comment essayer de réconcilier un peu tout ça. Comment faire assez light pour laisser passer la pilule mais sans faire si light que ça ne sert à rien ?...

Deux remarques :

- C'est sûr que s'il n'y aucune volonté de s'améliorer (que ça soit côté client ou équipe de dev), on ne s'améliorera pas. Cela passe par une prise de conscience de ce qui ne tourne pas rond dans les projets. Un client chez qui on a appuyé là où ça fait mal est un client d'autant plus volontaire pour s'impliquer dans le remède.

- Arrêtons de considérer le client comme quelqu'un qui devrait avoir la science infuse. Il ne connait pas tous ses besoins, c'est normal. Ils vont émerger au fur et à mesure et on va l'y aider. Il va changer de besoin, c'est normal. On va s'y adapter. Croire qu'il peut exister un plan initial parfait est une impasse.

[thierryler]

Bonjour.

Merci pour ces précisions.

Par définition, lorsqu'on a fini d'écrire un test pour lequel la fonctionnalité n'a pas encore été implémentée, le test échoue ! C'est aussi simple que [..]

Si pour toi, c'est ce que veut dire "faire échouer un test" alors tu n'auras aucun mal à faire du "3T" puisque c'est la manière simplifiée de le faire que je propose.

C'est sûr que s'il n'y aucune volonté de s'améliorer [..]

Je préfère ne pas entrer dans ce genre de considérations sur ce forum.

Arrêtons de considérer le client comme quelqu'un qui devrait avoir la science infuse. Il ne connait pas tous ses besoins, c'est normal. Ils vont émerger au fur et à mesure et on va l'y aider. Il va changer de besoin, c'est normal. On va s'y adapter. Croire qu'il peut exister un plan initial parfait est une impasse.

Dans 3T, si un besoin est ainsi identifié en cours de route, il peut faire l'objet d'un nouveau post-it. Par contre, il doit absolument être inclus dans les spécifications, comme cela devrait être le cas de manière générale d'ailleurs.

A propos, pensez à lire l’excellent tutoriel d'introduction aux TDD de Bruno : http://bruno-orsier.developpez.com/t...TDD/pentaminos