Discussion :

[thierryler]

Bonjour à tous,

Le TDD, la fameuse méthode de Développement Guidé par les Tests est devenue incontournable. Toutefois, elle n'est pas si simple à comprendre et à mettre en œuvre. Ce mini-article propose, comme version allégée du TDD, la "3T" qui, bien qu'incomplète, devrait suffire à la plupart des équipes.

La suite de l'article : http://thierry-leriche-dessirier.dev...va/methode-3t/

Bonne lecture.

Th.

[Darkaz]

Bon tutoriel.

mais je pense que l'outil qui permet de générer les tests depuis les spéc va être indispensable à tous le monde !

[Nithril]

C'est une approche que je ne partage pas.

L'étape 1 génère des interfaces à tous va et crée l'anti pattern 1 class <-> 1 interface. Une interface n'a d’intérêt que si elle apporte une plus value (plusieurs implémentations, interface au frontière...)

Il faut être pragmatique 2 et 3 peut très bien être 3 et 2 suivant le contexte.



Je conseille la lecture de l'article suivant Breaking Away From The Unit Test Group Think de Cedric Beust.

[thierryler]

Dans le cadre de la proposition "3T" il faut impérativement faire 1 puis 2 puis 3. Cette démarche permet de mécaniser l'écriture des tests. On écrit les tests avant le code. On dit d'abord ce qu'on veut tester.

Quand à l'antipattern, je préfère ne pas m'exprimer sur la question.

[Nithril]

Dans le cadre de la proposition "3T" il faut impérativement faire 1 puis 2 puis 3. Cette démarche permet de mécaniser l'écriture des tests. On écrit les tests avant le code. On dit d'abord ce qu'on veut tester.

Quand à l'antipattern, je préfère ne pas m'exprimer sur la question.

Le terme anti pattern est trop fort. Disons que cela génère du code inutile sans valeur. Si tu as une opinion différente je suis preneur

L'aspect mécanisations peut effectivement permettre à un débutant d’acquérir le réflexe test unitaire, mais avec l’expérience mon point de vu est que le coté dogmatique et figé 1->2->3 cède la place au pragmatisme

[thierryler]

A mon sens, c'est un bon compromis pour les aspects que j'ai l'habitude de rencontrer. Je propose "3T" mais je n'impose rien.

Edit : Comprend moi bien, je ne dis pas cela méchamment, mais il n'y a que 3 étapes dans "3T" alors si tu en enlèves une, ça devient "2T". Et si tu inverses 3 et 2, est ce encore du TDD ? J'ai longtemps réfléchi à une solution pour réussir à imposer une méthodologie de test, comme TDD, qui soit assez light pour ne pas susciter le rejet, mais assez stricte pour être mécanique, et puis qui guide/force le développeur vers des patterns qui fonctionnent.

J'insiste : 1 puis 2 puis 3...

Pourquoi cette démarche ? Tout simplement pour avoir une "normalisation" du processus, commune à toute l'équipe. Dès qu'un des développeurs commence à "être pragmatique" c'est la porte ouverte aux divergences.

Le point important de "3T" est de "bannir" tout pragmatisme ou "prise de tête" en recopiant le cahier des charges pour avoir "exactement" ce qui est demandé. A noter que le développeur peut "demander" que les specs soient complétées. S'il veut être pragmatique (ou réfléchir) c'est lors de la validation/lecture du cahier des charges qu'il faut le faire.

D'ailleurs (attention digression) la qualité d'un développeur ne vient pas de la maitrise pure de Java.

En ce qui concerne les interfaces, je n'ai pas très envie d'entamer la discussion (ici) mais je pense que c'est un point "puissant" dans Java. Même s'il est vrai que c'est un peu lourd d'avoir une interface et une classe, ce n'est pas sans valeur. Pense que tu auras peut-être d'autres classes plus tard. En outre, l'interface décrit ton service. C'est ton interface que tu dois exposer et non l'implémentation.

[bugsan]

J'aurais appelé l'interface "Calculette" tout court. On a tous pris de mauvaises habitude à tout suffixer par "service", "manager" ... selon moi toutes les classes "gèrent" et "servent" ..

[Franck Z]

Merci pour ce tutoriel.

J'aurais une question - qui me fera sûrement passer pour l'idiot du village, mais bon, poser une question si on ne sait pas tout, c'est aussi une bonne démarche, :

Est-ce qu'il y a une différence entre l'approche dirigée par les tests que tu décris et ce qu'on appelait la "programmation extrême" (XP) il y a quelques années ?

Merci, et pardon si je déclenche l'hilarité générale...

[thierryler]

Instinctivement j'aurais tendance à répondre que XP et TDD sont deux choses différentes. Toutefois je comprend pourquoi tu te poses cette question, qui n'est pas délirante du tout.

Edit : Dans l'article sur "3T" je donne d'ailleurs un très bon lien sur les TDD.

[deltree]

Bonjour,
j'ai du mal à voir exactement ce qui fait que le 3T n'est pas du TDD, mis à part qu'on ne s'impose pas de créer une simulation, et qu'on n'impose pas un cyle moins de 2minute pour le test, moins de 10 pour les cycles d'implémentation.

En fait j'envisage d'utiliser le 3T pour expliquer le TDD, parce que c'est beaucoup plus simple à comprendre pour les décideurs qui ne codent pas.

[_skip]

Le TDD est en effet l'une des recommandations du "extreme programming" mais c'est juste un point parmi parmi de nombreux autres dans la méthodologie XP.
Ce sont des notions différentes :

XP est ensemble de règles et recommandations qui couvre la gestion de projet d'équipe alors que le TDD est une technique de développement.

Pourquoi cette démarche ? Tout simplement pour avoir une "normalisation" du processus, commune à toute l'équipe. Dès qu'un des développeurs commence à "être pragmatique" c'est la porte ouverte aux divergences.

Le point important de "3T" est de "bannir" tout pragmatisme ou "prise de tête" en recopiant le cahier des charges pour avoir "exactement" ce qui est demandé. A noter que le développeur peut "demander" que les specs soient complétées. S'il veut être pragmatique (ou réfléchir) c'est lors de la validation/lecture du cahier des charges qu'il faut le faire.

C'est un point de vue, je pense que dans ton cas c'est la taille de l'équipe ou la présence de juniors qui force la normalisation du processus suivant les 3 étapes bien strictes. Il est totalement juste de dire qu'un code doit obéir aux spécifications et que l'approche 123 force la conformité.

Mais là où je rejoins Nithril, c'est qu'en développement, dès que les problèmes à traiter ne sont pas triviaux, il arrive souvent qu'en cours d'implémentation on découvre que la solution de départ n'était pas optimale et nécessite une révision qui prend en compte de nouveaux éléments. Et dans ces cas, on peut être amené à devoir par la même occasion jeter ou retoucher toute la batterie de tests initiales ce qui provoque du travail dans le vide.

C'est là que s'obliger a utiliser systématiquement le TDD peut être néfaste et qu'il peut être préférable de faire fonctionner, constater l'efficacité puis finalement blinder le tout avec des tests appropriés. Je pense que c'est ce qu'il a voulu dire.

Même s'il est vrai que c'est un peu lourd d'avoir une interface et une classe, ce n'est pas sans valeur. Pense que tu auras peut-être d'autres classes plus tard. En outre, l'interface décrit ton service. C'est ton interface que tu dois exposer et non l'implémentation.

J'avais l'intention de créer un débat sur les dangers de l'overengineering et la surabstraction...

[thierryler]

j'ai du mal à voir exactement ce qui fait que le 3T n'est pas du TDD

Tu peux voir "3T" comme une approche guidée vers un TDD simplifié.

En fait j'envisage d'utiliser le 3T pour expliquer le TDD, parce que c'est beaucoup plus simple à comprendre pour les décideurs qui ne codent pas.

Et je t'en remercie par avance ;-)

C'est un point de vue, je pense que dans ton cas c'est la taille de l'équipe ou la présence de juniors qui force la normalisation du processus suivant les 3 étapes bien strictes.

Les problèmes dont tu parles et que j'ai pu constater ne venait pas, en général, exclusivement des juniors. D'ailleurs les séniors utilisent souvent le mot magique "pragmatique" pour dire "j'ai pas envie de suivre la règle et je préfère faire à ma façon".

Le principe de "3T" est de fixer un cadre simple qu'il suffit de suivre pour être à peu près certain de réussir. Cela a évidement un cout.

Et dans ces cas, on peut être amené à devoir par la même occasion jeter ou retoucher toute la batterie de tests initiales ce qui provoque du travail dans le vide.

Ce n'est justement pas du travail dans le vide, bien au contraire. J'irais même jusqu'à dire que c'est là que ça se passe.

C'est là que s'obliger a utiliser systématiquement le TDD peut être néfaste et qu'il peut être préférable de faire fonctionner, constater l'efficacité puis finalement blinder le tout avec des tests appropriés. Je pense que c'est ce qu'il a voulu dire.

A mon sens, mais ça n'engage que moi, faire les tests après le dev, déjà ce n'est pas du TDD, et ensuite tu perds 50% de la puissance des tests. Tester un truc qui marche, c'est utile pour la non régression.

Faut aussi penser à un truc, c'est que tes tests sont aussi là pour prouver au client que le logiciel fonctionne. L'idéal serait même que ce soit le client qui écrive les tests. Justement dans "3T" c'est un peu le cas puisqu'on recopie carrément le cahier des charges, sans en changer le sens. C'est comme si le client avait lui-même rédigé les tests.

J'avais l'intention de créer un débat sur les dangers de l'overengineering et la surabstraction...

Pour moi, et là encore ça n'engage que moi, écrire une interface pour décrire un service, ça ne peut en aucun cas être une mauvaise pratique.

D'ailleurs, quand on utilise certains frameworks, comme Seam, on peut (la doc le recommande) n'avoir que les dépendances vers les API en dev (ie les interfaces dans Eclipse) et compléter avec les Impl pour la génération.

[thierryler]

Ajout, en FAQ, de la définition de "tâche terminée" dans le cadre de 3T.

Peut-on parler de "3T Terminée", soit de "3T bis" ? LOL

[thierryler]

On en parle ici : http://hingchanscrum.blogspot.com/20...ois-temps.html

[rhludovic]

Les tests en trois temps sont très intéressantes et je cherche un moyen de les implémenter dans mon travail. Bien que je développe en php principalement, la méthode me semble tellement efficace et facile.

Les articles m'ont fait prendre un peu de recule par rapport au codage pour réfléchir en terme de qualité, d’efficacité et de professionnalisme.

Aucun article ne m'a jamais autant inspiré. La plupart des méthodes sont soit trop lourdes a mettre en œuvre, soit du domaine du code uniquement. Je me suis rapidement intéressé a scrum aussi et l'intégration continue.

Je me demande encore pourquoi tant de méthodes ont été développés principalement sur la technologie java et pas des autres langages. Je me suis, d’ailleurs, rendu compte rapidement que la plupart des outils tournent autour de java (Jenkins pour l'intégration continue par exemple).

[Logan Mauzaize]

Ces méthodes sont nées en même temps que l'essor de Java, et aujourd'hui Java représente une belle part de marché.
D'ailleurs ces méthodes nécessitent pas mal d'outillage (Test unitaire, Mock, Couverture de code, Intégration Continue, Bug tracker, Analyse statique, etc.) Et la plupart de ces outils ont d'abord été créé pour Java.

Et parfois certains outils nécessitent des langages un peu évolué (Invocation dynamique, Introspection, etc.)


Concernant Jenkins/Hudson/Continuum/CruiseControl, ils peuvent parfaitement être utilisés pour d'autres types de projet que ceux en Java.

[thierryler]

Bonjour,

Aucun article ne m'a jamais autant inspiré.

Merci beaucoup. Je prend ça comme un compliment. Ca fait plaisir d'avoir des fans.

Même si PHP est un peu moins outillé que Java, ça l'est largement assez pour faire du 3T. Il faudrait demander à un spécialiste de PHP de nous indiquer les framework à utiliser.

[thierryler]

Je répond après plusieurs mois à propos de ça :

L'étape 1 génère des interfaces à tous va et crée l'anti pattern 1 class <-> 1 interface. Une interface n'a d’intérêt que si elle apporte une plus value (plusieurs implémentations, interface au frontière...)

En ce qui me concerne, je pense qu'on ne perd jamais à faire une I et une C. Et c'est ce que je recommande dans le cadre de 3T. Toutefois, après avoir pesé le pour et le contre (c'est ce qui m'a pris aussi longtemps), je pense qu'on peut se contenter de faire une classe seulement (donc pas de I). Mais dans ce cas, lors du premier temps, il faut faire des méthodes vides, qui renvoient de UnsuportedOperationException par exemple. Néanmoins, je voudrais insister sur le fait que je ne cautionne pas cette pratique.

[Logan Mauzaize]

Disons que 3T étant une méthode "rapide", c'est dommage de perdre un peu de temps avec ça. Même si avec un IDE moderne ça prend pas plus de quelques secondes à générer l'implémentation.

Ensuite pour avoir quelques projets où cette pratique a été appliquée, ça devient très lourd à la maintenance. Et sans un IDE moderne c'est un calvaire de naviguer entre les classes et les implémentations.
Ca alourdie considérablement la code sans rien lui apporter.

Je préfère la méthode de refactorisation si j'ai besoin de généraliser ce qui a commencé par être spécifique, plutôt que commencer par généraliser quelque chose qui a uniquement pour but d'être spécifique.
D'ailleurs il me semble que c'est la préconisation d'XP en matière de "pragmatisme" : ne fait que ce qui est utile.
Il est intéressant de noter que c'est également un élément clé des UP.

[thierryler]

Je vous encourage à lire également, si ce n'est pas déjà fait, les deux articles suivants :

* Les Tests en Trois Temps (3T) en pratique
"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.
http://thierry-leriche-dessirier.dev...t-en-pratique/

* 3T en pratique, application au calcul de la suite de Fibonnaci, en 5 minutes
Ce petit tutoriel montre comment mettre en œuvre 3T (Tests en Trois Temps), pour développer une fonctionnalité simple (la suite de Fibonnaci dans l'exemple) en s'aidant des tests, le tout en quelques minutes.
http://thierry-leriche-dessirier.dev...acci-3t-5-min/

Par ailleurs, je voudrais préciser que je suis preneur de toutes les remarques, positives ou négatives, pour faire évoluer la "méthode" vers le meilleur compromis.