Discussion :

[thierryler]

Bonjour,

Je vous propose un nouvel article dans les séries "en 5 minutes" et "3T ou les Tests en Trois Temps", intitulé "3T en pratique, application au calcul de la suite de Fibonnaci, en 5 minutes".

Vous trouverez cet article à l'adresse suivante :
http://thierry-leriche-dessirier.dev...acci-3t-5-min/

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.

A noter que vous retrouverez mes autres articles de ces séries à l'adresse suivante
http://thierry-leriche-dessirier.dev...#page_articles

Bonne lecture.

[Mandraxx]

Bonjour,

Très intéressant comme approche : simple et efficace.

Merci beaucoup.
@+

[thierryler]

Merci. Je vais rougir.

Vous pouvez également consulter les autres articles sur 3T ainsi que. Eux de la série "en 5 minutes".

[alex_vino]

Tres bon article, bonne idée ce cahier des charges et l'organisation des tests autour de celui-ci.

Connaitriez-vous de bons tutoriels sur les différents scénarios de test? Par exemple pour la suite de Fibonacci, l'oubli d'une regle dans le cahier des charges pourrait générer une erreur pour 1 ou plusieurs valeurs. Je ne sais pas si vous voyez ce que je echerche, mais en gros ce sont les diagrammes qui permettent d'organiser l'ordre des tests et les différentes valeurs a tester pour optimiser au mieux le processus.

Vous pouvez également consulter les autres articles sur 3T ainsi que. Eux de la série "en 5 minutes".

Ou cela?

[thierryler]

Bonjour,

En fait, je ne comprend pas très bien la question.

Mes autres articles sont disponibles ici :
http://thierry-leriche-dessirier.dev...#page_articles

[romaintaz]

Bonjour,

Je n'ai pas encore lu ton article sur les 3T, je ne parle donc qu'en connaissance de ce qu'est le TDD. Et je dois dire que ce qui est écrit ici n'en est hélas pas (ou alors de loin).

Pour rappel, l'idée du TDD est la suivante (dans ses grandes lignes) :

1. J'écris un test, qui naturellement va échouer (parce que la méthode n'existe pas, ou qu'elle n'est pas encore capable de traiter le test que je viens d'écrire).
2. J'écris le code qui va me permettre de faire marcher mon test.
3. Je vérifie que mon test passe désormais au vert.
4. Je refactore mon code pour le rendre plus clair, plus efficace (avec, comme filet de sécurité, l'ensemble des tests déjà écrits).
5. On recommence à l'étape 1, avec un nouveau cas de test.

A la fin de chaque "itération" TDD, le code doit fonctionner, et tous les tests - y compris ceux qui ne sont pas directement liés à ma fonctionnalité courante - doivent être au vert.

Dans ton article, il y a plusieurs "infractions" au TDD :

• On commence par écrire tous les tests avant de toucher à la fonctionnalité.
• On ne dispose d'un code qui compile qu'à la fin du développment de la fonctionnalité, ce qui va empêcher le développeur de réaliser des commits atomiques (c'est-à-dire qu'il ne commitera qu'une seule fois, à la toute fin).
• Quid du refactoring du code ? D'après ce que je lis ici (mais peut-être l'exemple est-il trop simple ?), on ne fait qu'ajouter du code à notre calculatrice Fibonacci, sans avoir à refactorer ce que l'on a fait dans les étapes précédentes.

Un point également sur la façon d'écrire les tests unitaires.
Pour moi, un test ne devrait pas (ou alors peu) être commenté, car il doit être "auto-explicatif", en particulier parce que lorsqu'un test échoue, on va souvent le savoir par mail ou via l'outil d'intégration continue (je parle en dehors du moment où je suis en train d'écrire ce test, dans mon cycle TDD).
Or, si Jenkins m'avertit que le test "testFibonacci_RG024_3_a" échoue, ça ne va pas m'être d'une grande utilité, car je ne sais pas exactement à quoi correspond ce test. Surtout si ce n'est pas moi qui ait écrit ce test.
S'il avait été nommé par exemple "fibonacci_of_3_should_be_2", alors c'est beaucoup plus clair.
De même, au lieu d'avoir "testFibonacci_RG024_4_a", je préfèrerais avoir un "fibonacci_cant_calculate_negative_value"...

Je passerais finalement sur l'aspect "Documentation Driven Development" où l'ajout massif de commentaires (aussi bien dans le code que dans les tests) est, de mon point de vue, plus un handicap qu'un avantage, rendant le code moins lisible, et nécessitant une maintenance assez lourde...

Voyons les choses positivement : tu cherches à sensibiliser les gens sur l'importance des tests (unitaires), et l'intérêt que l'on a de les écrire avant le code. Et ça s'est bien. Mais tant qu'à faire, autant respecter les principes du TDD...


ps: le graphique en III-C n'apporte pas grand chose, surtout que l'on ne voit que 2 courbes, alors que l'on s'attend à 4 d'après la légende.