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

[Bobby McGee]

Bonjour,

Je vous remercie pour cet article que je trouve de grande qualit�.

En tant que prof d'info, je vais tenter de le transcrire dans un contexte p�dagogique pour faire d�couvrir le TDD aux �tudiants. Je pr�cise qu'avant d'enseigner, j'ai �t� responsable technique dans une SSII et j'ai eu l'occasion de me frotter aux joies des tests unitaires, avec plus ou moins de bonheur. Je vais pouvoir mesurer le chemin parcouru depuis.

Vanessa ne joue pas un r�le important dans l'histoire. Elle ne fait m�me pas partie du projet. Elle incarne l'�l�ment perturbateur : ses passages dans le bureau font chuter dramatiquement le niveau g�n�ral de concentration et la productivit� de l'�quipe. Il faut pr�ciser que Vanessa est charmante.

C'est mon passage pr�f�r�. On sent une connaissance pointue du fonctionnement d'une �quipe de d�veloppeurs

[thierryler]

Merci pour ces compliments.

Vous enseignez dans quelle �cole ? N'h�sitez pas � donner l'URL de l'article � vos �tudiants.

Le cas de Vanessa n'est pas si trivial qu'il en a l'air. Dans la plupart des m�thodologies, on oublie � quel point certains �l�ments perturbateurs peuvent changer la donne. Scrum, par exemple, introduit le concept de "productivit� r�elle" qui suppose que les d�veloppeurs ne peuvent pas rester concentr�s et/ou productif pendant 8 heures. On tient compte de la productivit� constat�e dans les plannings.

Sur certains projets j'ai constat� que la productivit� ne d�passe pas 2-3 heures par jour. Et certaines �quipes l'ont vraiment compris. C'est par exemple de cas de Github qui autorise ses membres � travailler sur des projets "perso" pour se changer les id�es.

[Ali HOUCINE]

Merci Thierry

[zakarisz_ghent]

J'ai d�vor� vos 2 articles � propos de 3T et je me posais une question :
Comment peut-on g�rer la cr�ation de l'interface graphique ?

Je vois une approche du style :

• Un dessin de la fen�tre sur le "post-it jaune" au lieu de la petite phrase de description
• "dessin" (wysiwyg ou bien cod� � la main, peut importe) dans le premier temps, � la place du code des interface
• un test d'IHM pour le second temps au lieu du test d'IHM (un outils � me conseiller pour Java/SWING ?)
• faire le lien entre la partie m�tier et l'IHM dans le 3�me temps, en guise de "vrai code"

Cela vous semble-t-il correct ou avez-vous une autre approche � sugg�rer ?

Merci pour vos articles de qualit� et merci d'avance pour vos r�ponses