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.