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.

[thierryler]

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

Oui. C'est volontaire et assumé. Il faut bien comprendre que 3T est une version simplifiée des TDD. Elle s'en inspire dans ce qui me semble être le plus intéressant mais ce n'est pas des TDD...

Je trouve (et je ne suis pas le seul) que les TDD sont trop complexes. L'idée de 3T est d'avoir une démarche quasi systématique, dont chaque étape peut être réalisée par une personne différente.

On commence par écrire tous les tests avant de toucher à la fonctionnalité.

Exactement. Je précise qu'on n'écrit que les tests liés à la fonctionnalité. Toutefois, rien n’empêcherait d'écrire directement tous les tests. Il faudrait mesurer si ce n'est pas contre productif.

Comme, dans 3T, ce sont des personnes différentes qui écrivent les tests et le code de production, c'est logique que la personne écrive directement tous les tests. En fait je trouve que la démarche d'écrire et de coder un test à la fois, c'est lent et contre productif. C'est la porte ouverte à plein de dérives que 3T cherche à combattre.

On ne dispose d'un code qui compile qu'à la fin du développment de la fonctionnalité

Je ne vois pas pourquoi tu penses ça. Bien au contraire. Avec 3T, ton code doit toujours compiler. Et tes tests te disent bien ce qui est déjà fonctionnel ou non.

Quid du refactoring du code ? D'après ce que je lis ici (mais peut-être l'exemple est-il trop simple ?)

Oui c'est l'exemple qui est trop simple. En plus, dans le cas de figure présenté, on suppose que c'est la première fonctionnalité de la calculette, donc forcément, il n'y a rien d'autre à refactorer lol. Dans le deuxième article sur 3T, je montrait justement le cas d'un développement complémentaire, mais sans gros refacto non plus. C'est un peu dur à montrer dans un article en 5 minutes. Je peux ajouter ça en annexe si on me donne un bon exemple.

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.

En fait, ton hudson t'indique bien que c'est la regle RG024.3.a qui échoue. Or c'est surtout le CP qui regarde les rapports d'hudson. Lui ça lui parlera bien plus que l'info technique "fibonacci_of_3_should_be_2".

Si le CP fait l'approximation que tous les tests ont la même valeur, et que l'application est composée de N tests pour couvrir les N règles du cahier des charge, alors il peut suivre l'évolution du projet en fonction de l'évolution du vert/rouge de surefire par exemple.

Faut bien comprendre que 3T est une "méthode pour les faignants" où on a un document de référence, qui te donne l'interface de référence, qui te donne les tests de références, puis enfin le code de production.

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...

Je crois que c'est un point faible effectivement, mais aussi un point fort. Je dois préciser que 3T recommande de ne pas versionner les tests. Si un test change (ie une règle change) on écrit un nouveau test et on efface l'ancien. Pour l'occasion, une nouvelle règle est créée. On ne change pas une règle, on la supprime et la remplace par une autre.

cf. http://thierry-leriche-dessirier.dev...ratique/#LIV-A

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...

En fait, il y a plein de trucs qui me gênent dans les TDD, et ce sont notamment ceux pour lesquelles tu as trouvé des différences. 3T est une méthode qui s'inspire des TDD et qui essaie d’apporter des réponses à chacun des acteurs du projet.

Je te renvoie vers les autres articles : http://thierry-leriche-dessirier.dev...#page_articles


Je pensais aussi à l'opportunité de remplacer/compléter la doc par des annotations...

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.

Les courbes sont effectivement superposées. J'ai hésité avant d'utiliser ce graphe.


J'aurais pu rappeler ce passage :
http://thierry-leriche-dessirier.dev...n-pratique/#LI

Pour rappel, "3T" est une version simplifiée (et une vision personnelle) des TDD (les Développements Guidés par les Tests). Je suis parti du constat que les TDD sont souvent accusés, à tort, de ralentir les projets, d'être complexes et de couter cher. Le principe de base de "3T" est de mécaniser le processus de développement en subdivisant les interventions et les rôles. Chaque sous-partie devient d'autant plus simple ; il suffit la plupart du temps de recopier le cahier des charges. Au prix de quelques légères entorses aux TDD, les développeurs peuvent alors concentrer leur énergie sur la qualité de leurs productions, tout en ayant une vitesse de développement élevée et un retour sur investissement fort.

...

Il est important de noter que "3T" n'est en aucun cas une méthode "officielle", contrairement aux TDD. "3T" est une proposition de simplification des TDD qui devrait suffire à la plupart des équipes. En effet, mon expérience personnelle, liée à l'utilisation de Xp, de Scrum et bien entendu des TDD, me conduit à croire que les développeurs n'utilisent pas tout (certains aspects des TDD sont difficiles à faire et mangent beaucoup de temps) mais se concentrent sur certains points importants dont "3T" est un résumé cadré. On peut voir "3T" comme la formulation d'une pratique de simplification dont l'objectif est de gagner du temps (et de l'argent).

[romaintaz]

Thierry,

Oui. C'est volontaire et assumé. Il faut bien comprendre que 3T est une version simplifiée des TDD. Elle s'en inspire dans ce qui me semble être le plus intéressant mais ce n'est pas des TDD...

Effectivement, mais ton article parle beaucoup du TDD (et aussi du 3T), mon souci étant qu'un néophyte n'arrivera pas à distinguer les deux.

Je trouve (et je ne suis pas le seul) que les TDD sont trop complexes. L'idée de 3T est d'avoir une démarche quasi systématique, dont chaque étape peut être réalisée par une personne différente.

Mon point de vue est assez différent. Le principe du TDD est ultra-simple. Au début il y a certes un "choc culturel" (surtout quand on a une certaine expérience) du fait de coder les tests avant le code en lui-même. Mais en dehors de cela, il n'y a rien de compliqué dans le principe du TDD.

Là où ça se complique, c'est de savoir définir correctement des tests, et également de savoir les écrire. S'il est vrai que pour du code "simple" comme Fibonacci, le problème ne se pose pas, ce n'est plus le cas lorsque l'on attaque des vraies applications du monde réel. Définir des mocks n'est pas toujours simple, écrire un vrai test unitaire (i.e. en isolation) dans un environnement complexe l'est encore moins.
Sur cet aspect de la complexité à écrire des tests corrects, je ne vois absolument pas en quoi 3T est plus simple que le TDD.

Exactement. Je précise qu'on n'écrit que les tests liés à la fonctionnalité. Toutefois, rien n’empêcherait d'écrire directement tous les tests. Il faudrait mesurer si ce n'est pas contre productif.

Hum, vouloir écrire tous les tests de toute l'application avant même de commencer à écrire l'application ?
Je ne vois pas comment cela pourrait être envisageable. Cela signifierait par exemple avoir une application ne pouvant compiler qu'à la toute fin. Et d'avoir un cahier des charges qui n'évolue (presque) pas.

Comme, dans 3T, ce sont des personnes différentes qui écrivent les tests et le code de production, c'est logique que la personne écrive directement tous les tests. En fait je trouve que la démarche d'écrire et de coder un test à la fois, c'est lent et contre productif. C'est la porte ouverte à plein de dérives que 3T cherche à combattre.

Je ne suis pas convaincu. Déjà, faire écrire les tests et le code systématiquement par deux personnes différentes, je trouve cela complexe en pratique. De même, si l'écriture de tests fonctionnels sont tout à fait à la portée des MOA, l'écriture de tests en Java (ou autre langage) n'est plus dans leur périmètre, sans compter les tests purement techniques. De même, il y a des contraites techniques ou d'architecture qui interviennent dans l'écriture des tests que seuls des développeurs peuvent prendre en charge.
Mais du coup, je me demande si ton 3T ne devrait pas plutôt lorgner du côté du BDD que du TDD ?

Je ne vois pas pourquoi tu penses ça. Bien au contraire. Avec 3T, ton code doit toujours compiler. Et tes tests te disent bien ce qui est déjà fonctionnel ou non.

J'ai du rater une étape alors. Comment fais-tu pour qu'une personne écrive les tests, et une autre le code correspondant sans qu'il n'y ait de commit de la première personne (et donc commits de code non compilable ou avec des erreurs) ? A moins de partager sa machine, ou faire une sorte de pair programming (ce qui est loin d'être toujours évident) ?

Oui c'est l'exemple qui est trop simple. En plus, dans le cas de figure présenté, on suppose que c'est la première fonctionnalité de la calculette, donc forcément, il n'y a rien d'autre à refactorer lol. Dans le deuxième article sur 3T, je montrait justement le cas d'un développement complémentaire, mais sans gros refacto non plus. C'est un peu dur à montrer dans un article en 5 minutes. Je peux ajouter ça en annexe si on me donne un bon exemple.

Ok pour "l'excuse" du cas d'exemple trop simple. Mais le 3T, si je le comprends bien, c'est :

1. J'écris une interface (d'ailleurs pourquoi forcer l'écriture d'une interface ? On arrive vite au syndrome 1 interface pour 1 implémentation).
2. J'écris mes tests.
3. J'écris mon code.

Il n'y a pas vraiment de partie propre au refactoring. Mais c'est peut-être du chipotage de ma part sur ce point, on pourrait considérer qu'on réalise cela dans la 3e étape...
Toutefois, peut-être qu'il serait mieux de le dire explicitement, pour que l'on garde à l'esprit le "first, make it work. Then, make it fast" (i.e. fais en sorte que ça marche, optimise seulement après).

En fait, ton hudson t'indique bien que c'est la regle RG024.3.a qui échoue. Or c'est surtout le CP qui regarde les rapports d'hudson. Lui ça lui parlera bien plus que l'info technique "fibonacci_of_3_should_be_2".

Là, je ne suis pas d'accord !
Déjà, je félicite le chef de projet qui connait l'ensemble des règles métiers par leurs identifiants (qui plus est sont assez obscurs - que signifie le suffixe 3.a pour la règle RG024 déjà ?).
Franchement, je pense que même un chef de projet préfère savoir que le test qui échoue est celui qui est censé vérifier que Fibonacci de 3 vaut 2, plutôt que le test qui vérifie la règle RG024.3.a.
Mais bon, là c'est plus une convention de nommage des tests, et ce n'est pas directement lié au fait d'appliquer 3T, TDD ou autre...

Ensuite, les rapports de l'intégration continue (ou mieux, de Sonar) sont loin d'être la seule préoccupation du CP. Un développeur qui ne s'en préoccupe pas est pour moi un mauvais développeur, car il ne s'inquiète même pas de la qualité de son code !

Si le CP fait l'approximation que tous les tests ont la même valeur, et que l'application est composée de N tests pour couvrir les N règles du cahier des charge, alors il peut suivre l'évolution du projet en fonction de l'évolution du vert/rouge de surefire par exemple.

Merci de décrire le genre de chef de projet que je ne souhaite surtout pas avoir Ce genre de reflexion me fait penser au concept ô combien trompeur du "jour/homme".
Dans ton exemple de Fibonacci, tu as des tests super simples (dire que Fibonacci(3) = 2 par ex.) et d'autres qui peuvent s'avérer plus complexes (toute exécution de Fibonacci doit prendre moins d'1 seconde).
Avec ce genre de considération, on peut très facilement tomber dans le principe du "80/20". Implémenter les 80 premiers % des tests peut te prendre 20% de ton temps, alors que les 20 derniers % te prendront 80% du temps.

Si l'un des "avantages" du 3T est de donner ce genre d'indicateurs à ton CP, alors c'est se tirer une balle dans le pied (et avec un Magnum 47 au minimum) !

Je crois que c'est un point faible effectivement, mais aussi un point fort. Je dois préciser que 3T recommande de ne pas versionner les tests. Si un test change (ie une règle change) on écrit un nouveau test et on efface l'ancien. Pour l'occasion, une nouvelle règle est créée. On ne change pas une règle, on la supprime et la remplace par une autre.

Tu ne versionnes pas les tests ? Voilà une idée bien étrange !
Que se passe t'il si ton test est faux ? Tu le jettes entièrement et en recrées un nouveau ?
L'écriture d'un test n'est pas chose aisée (dans la vraie vie, j'entends), alors si un test évolue et que je dois tout refaire, que de temps perdu !
Quel est l'intérêt de ne pas considérer les tests comme du code...

En fait, il y a plein de trucs qui me gênent dans les TDD

Mais quoi plus précisément ? Comme expliqué au tout début, TDD c'est une pratique très basique à la base. Rien de miraculeux. La vraie complexité, à nouveau, c'est de bien écrire les tests.
A la limite, la seule grosse distinction que je vois entre les 3T et le TDD, c'est la façon dont on écrit la "specification des tests".

Romain

[romaintaz]

Pour réagir à ton edit :

Je suis parti du constat que les TDD sont souvent accusés, à tort, de ralentir les projets, d'être complexes et de couter cher.

Dans l'esprit des "gars d'en haut", ce n'est pas le TDD qui coute cher, ce sont les tests ! Quand un développeur écrit un test, il n'écrit pas du code qui va en production, donc je le paie à rien faire !
Suivant cet état d'esprit (déplorable), faire du TDD ou du 3T revient à peu près au même (et je suis gentil, je ne parle pas de ces faignasses qui font du pair programming où on paie 2 gars à faire le boulot d'un seul ).

il suffit la plupart du temps de recopier le cahier des charges.

Encore faut-il en avoir un. Qui soit globalement stable. C'est dur dans la vraie vie !

Au prix de quelques légères entorses aux TDD, les développeurs peuvent alors concentrer leur énergie sur la qualité de leurs productions, tout en ayant une vitesse de développement élevée et un retour sur investissement fort.

Personnellement, je n'aime pas trop cette idée de détacher complètement le développeur des tests. C'est son travail aussi. Mais bon, après il faut voir comment cela se réalise concrètement...

certains aspects des TDD sont difficiles à faire et mangent beaucoup de temps

Encore une fois : quoi au juste ? Si c'est l'écriture des tests, même en 3T il faut les coder...

[thierryler]

Je vais essayer de répondre à tout ça. D'abord il faut comprendre que 3T est une "méthode" que j'essaie de formaliser. Elle s'inspire des TDD et aussi, comme tu l'as deviné, des BDD. Pendant longtemps, je n'étais pas satisfait des TDD pour les raisons que je vais expliquer plus tard. Toujours est-il que cet échange m'aide à mettre au point 3T et/ou à l'améliorer. D'ailleurs, je suis toujours à la recherche de partenaires pour m'aider à formaliser 3T.

Le truc qui me gène le plus avec les TDD, c'est que les développeurs (et leurs chefs) ne savent pas vraiment par quel bout le prendre. Chacun voit midi à sa porte, ses propres contraintes et besoins, ses attentes personnelles, etc. L'idée de 3T, c'est de dire clairement comment faire les choses, dans quel ordre, qui fait quoi, etc.

Alors...

Dans l'esprit des "gars d'en haut", ce n'est pas le TDD qui coute cher, ce sont les tests ! Quand un développeur écrit un test, il n'écrit pas du code qui va en production, donc je le paie à rien faire !

Oui exactement. C'est un des points auquel je me suis attaché. Les TDD doivent permettre de réduire les coûts. Ils permettent de développer plus vite et avec une meilleure qualité. Le surcoût généré par l'écriture des tests doit normalement être contre balancé par la vitesse gagné sur la phase de développement du code de production et, surtout, sur les bugs évités.

Seulement, voilà, les "gars d'au dessus" ne comprennent pas ce genre de raisonnement. Le "gars d'au dessus", il voit les dépenses mais pas les gains. Il se dit seulement que les tests représente du temps de développement en plus sans voir le temps qu'on gagne sur le codage de production. Il se dit qu'il paye déjà très cher des prestataires experts et qu'il ne devrait pas avoir à financer leurs lubie pour les tests. Il se dit, souvent à juste titre, que ça va encore plus embrouiller les équipes. Bref, il n'a pas envie de payer pour ça.

Du coup, je me suis demandé comment faire en sorte que les "tests ne coûtent pas plus cher" directement, quitte à faire des concessions sur d'autres choses. L'idée est de trouver un compromis acceptable dans la plupart des cas. Pour cela, je me suis demandé sur quoi je pouvais m'appuyer pour valider l'écriture des tests. La réponse a été de s'appuyer sur le cahier des charges. En effet, celui-ci a été écrit par des supers experts fonctionnels (payés le double de moi) et doit donc être parfait LOL. En tous cas, puisque le chef me balance les spécifications dans la tronche, autant rebondir dessus.

Dans un premier temps, un développeur (et non un fonctionnel) va recopier le cahier des charges sous forme d'interface. Ce sont des copié-collés relativement simples, qui ne coûtent donc pas cher. C'est presque un travail de grouillot... J'exagère mais vous comprenez l'idée. C'est gratos... Ca le chef, il aime toujours.

Ensuite, un autre développeur va écrire tous les tests de la fonctionnalité, d'un coup. Il s'appuie pour cela sur l'interface précédemment écrite. Il recopie les numéros des règles pour bien référencer les demandes.

Et puis, enfin, on développe comme on le ferait avec les TDD. Alors évidement, je prend des raccourcis, mais ça me semble largement raisonnable. L'idée, c'est surtout de mécaniser la partie que le chef n'a pas envie de payer.

Remarque : En pratique, le cahier des charge est souvent un assemblage hasardeux de post-it mais ça marche pareil, et c'est même encore mieux.

Suivant cet état d'esprit (déplorable), faire du TDD ou du 3T revient à peu près au même

Non. Justement... Quand tu fais du TDD classique, le chef se dit qu'il paye pour des choses en plus, qu'il n'a pas demandé et ça le gonfle. En plus il se dit que ça crée du risque si les développeurs s'embrouillent. Avec 3T, le chef se dit que ça ne coûtera rien de plus, si ce n'est des copié-collés vite faits. Du coup il te laisse faire. Au pire il se dit que c'est juste une lubie. Au mieux il comprend l'intérêt de la démarche et va s'en servir pour s'auto promouvoir auprès de ses contacts.

Encore faut-il en avoir un. Qui soit globalement stable. C'est dur dans la vraie vie !

Stable ou pas, ça ne change rien au principe. Je fais ça avec des post-it qui se décollent. Il faut tout de même que ça reste stable un minimum de temps pour avoir le temps d'écrire le code.

Personnellement, je n'aime pas trop cette idée de détacher complètement le développeur des tests. C'est son travail aussi. Mais bon, après il faut voir comment cela se réalise concrètement...

Là tu n'as pas compris. Ce sont bien les développeurs qui écrivent l'interface, les tests et le code de production. Les fonctionnelles écrivent seulement le cahier des charges.

Encore une fois : quoi au juste ? Si c'est l'écriture des tests, même en 3T il faut les coder...

Oui, dans tous les cas, il faut les coder LOL. Le petit avantage avec 3T, c'est qu'on te dit directement comment les écrire, par qui, etc. Ça aide... un peu...

Mon point de vue est assez différent. Le principe du TDD est ultra-simple. Au début il y a certes un "choc culturel" (surtout quand on a une certaine expérience) du fait de coder les tests avant le code en lui-même. Mais en dehors de cela, il n'y a rien de compliqué dans le principe du TDD.

Je suis complètement d'accord avec ça.

Là où ça se complique, c'est de savoir définir correctement des tests, et également de savoir les écrire. [..]
Sur cet aspect de la complexité à écrire des tests corrects, je ne vois absolument pas en quoi 3T est plus simple que le TDD.

Très précisément, on se pose déjà des questions sur comment bien tester. Si on doit encore se poser des questions sur la manière d'organiser tout ça, et ben ça part vite en vrille. Et là je ne parle même pas des équipes qui n'arrivent pas à définir une organisation commune et claire.

Hum, vouloir écrire tous les tests de toute l'application avant même de commencer à écrire l'application ?
Je ne vois pas comment cela pourrait être envisageable. Cela signifierait par exemple avoir une application ne pouvant compiler qu'à la toute fin. Et d'avoir un cahier des charges qui n'évolue (presque) pas.

Le faire pour toute l'application, je pense que ça ne marcherait pas. On peut déjà se limiter au périmètre du sprint en cours. C'est déjà pas mal.

Si le cahier des charges change, déjà ça veut dire qu'on change de sprint ou que quelqu'un a mal fait son travail, et bien, on change les tests en conséquence.

Je ne suis pas convaincu. Déjà, faire écrire les tests et le code systématiquement par deux personnes différentes, je trouve cela complexe en pratique. De même, si l'écriture de tests fonctionnels sont tout à fait à la portée des MOA, l'écriture de tests en Java (ou autre langage) n'est plus dans leur périmètre, sans compter les tests purement techniques. De même, il y a des contraites techniques ou d'architecture qui interviennent dans l'écriture des tests que seuls des développeurs peuvent prendre en charge.

En fait, dans 3T, l'idéal est que deux phases successives ne soient pas prises en charge par le même développeur. Comme ça, on évite les raccourcis, les tests de complaisances, les portions de code que seul la personne peut comprendre, etc. En partageant le travail, d'abord on simplifie chaque partie, ensuite on s'oblige à bien faire chaque partie, pour peu que l'équipe joue le jeu.

J'ai du rater une étape alors. Comment fais-tu pour qu'une personne écrive les tests, et une autre le code correspondant sans qu'il n'y ait de commit de la première personne (et donc commits de code non compilable ou avec des erreurs) ? A moins de partager sa machine, ou faire une sorte de pair programming (ce qui est loin d'être toujours évident) ?

La première personne écrit une interface et une implémentation vide. Ca ne crée aucun problème de compilation. Il commit. La seconde personne écrit des tests qui restent rouges. On n'a toujours pas de problème de compilation. Il commit. La troisième personne écrit le code de production. Là non plus, aucun problème de compilation. Le seul souci qu'on peut rencontrer, ça serait que quelqu'un utilise l'interface et l'implémentation vide sans savoir qu'elle est vide. Mais là, il va juste se manger une UnsupportedOperationException facile à détecter. Et, si c'est réalisé dans le cadre d'un sprint, ce genre de situation ne devrait pas arriver... Là j'emploie volontairement le conditionnel. En effet, 3T est une "méthode" qui "suffit" dans la "plupart" des cas...

Il n'y a pas vraiment de partie propre au refactoring. Mais c'est peut-être du chipotage de ma part sur ce point, on pourrait considérer qu'on réalise cela dans la 3e étape...

Effectivement, je n'ai pas beaucoup insisté là dessus. Il faut dire que mes exemples ne s'y prêtent pas vraiment. Ils sont trop simples. Alors oui, faire du 3T ne dispense pas de faire de la qualité LOL

Déjà, je félicite le chef de projet qui connait l'ensemble des règles métiers par leurs identifiants (qui plus est sont assez obscurs - que signifie le suffixe 3.a pour la règle RG024 déjà ?).

Hé hé hé. En fait il faut se mettre en condition. Le chef a le cahier des charges sur son bureau LOL. Et puis, souvent, le CP n'est un techos. C'est juste un manager qui gère des gens et des chiffres. Il s'appuie sur les données qu'il maîtrise.

Ensuite, les rapports de l'intégration continue (ou mieux, de Sonar) sont loin d'être la seule préoccupation du CP. Un développeur qui ne s'en préoccupe pas est pour moi un mauvais développeur, car il ne s'inquiète même pas de la qualité de son code !

Ah si seulement... LOL
Je pense que la plupart des développeurs se concentrent malgré tout sur leur périmètre.

Disons un sonar associé à un hudson et plein de plugins divers ;-)

Merci de décrire le genre de chef de projet que je ne souhaite surtout pas avoir Ce genre de reflexion me fait penser au concept ô combien trompeur du "jour/homme".
Dans ton exemple de Fibonacci, tu as des tests super simples (dire que Fibonacci(3) = 2 par ex.) et d'autres qui peuvent s'avérer plus complexes (toute exécution de Fibonacci doit prendre moins d'1 seconde).
Avec ce genre de considération, on peut très facilement tomber dans le principe du "80/20". Implémenter les 80 premiers % des tests peut te prendre 20% de ton temps, alors que les 20 derniers % te prendront 80% du temps.

Si l'un des "avantages" du 3T est de donner ce genre d'indicateurs à ton CP, alors c'est se tirer une balle dans le pied (et avec un Magnum 47 au minimum) !

J'étais certain de me prendre ce bon argument en retour LOL Disons qu'un bon CP, qui sait faire la part des choses, pourra utiliser quelque chose qui ressemble à ça. Il peut associer ça avec un système de pondération par exemple, ou tout autre mécanisme qu'il jugera pertinent en fonction de son cas de figure spécifique.

Par exemple, si c'est dans du scrum, avec des unités de temps bien choisies, ça peut rendre bien. Mais là autant utiliser directement le burndown...

Là je suis preneur de toutes les bonnes idées pour mécaniser cette partie.

Tu ne versionnes pas les tests ? Voilà une idée bien étrange !

Non, pas dans 3T. En effet, un test est associé à une règle. Si la règle X change, je crée une nouvelle règle X' et je supprime la règle X. Je crée un test T' en fonction et supprime l'ancien test T, qui n'a plus de raison d'être. Je me suis rendu compte que le versionnement des règles, c'est vite le bazar.

Quel est l'intérêt de ne pas considérer les tests comme du code...

Si si, les tests sont du code. Ils font partie du livrable.

Bon ça fait une réponse super longue mais ça fait avancer le sujet.

[thierryler]

Je précise que plusieurs équipes utilisent actuellement 3T. Les retours sont globalement positifs pour l'instant. Les développeurs ont surtout apprécié d'avoir une sorte de guide.

[alex_vino]

Vous faites un super bon boulot avec votre débat les gars.
Merci c'est tres formateur.

Je vous laisse continuer

PS: Je comprend tres bien le principe des TDD et 3T, j'y arrive pour une classe (style Fibonacci) mais je ne sais pas du tout comment faire a partir du moment ou il y a plusieurs classes et reliées a une base de données. Auriez-vous un tuto, un lien ou un exemple du principe?

[thierryler]

Vous faites un super bon boulot avec votre débat les gars.
Merci c'est tres formateur.

Oui ça m'oblige à reformuler et rendre plus claires les explications, ce qui est plutôt positif.

Je comprend tres bien le principe des TDD et 3T, j'y arrive pour une classe (style Fibonacci) mais je ne sais pas du tout comment faire a partir du moment ou il y a plusieurs classes et reliées a une base de données. Auriez-vous un tuto, un lien ou un exemple du principe?

Alors, comme l'a précisé romaintaz, 3T diverge pas mal des TDD, même sur le calcul de la suite de Fibonacci. Cela dit, tu peux appliquer les deux quasi indifféremment sur des exemples simples. Ca ne changera pas grand chose pour toi. Disons que 3T sera peut-être un peu plus directif.

Pour répondre plus précisément à ta question. Je te conseille d'abord la lecture de deux autres articles sur 3T :

* 3T : les Tests en Trois Temps : http://thierry-leriche-dessirier.dev...va/methode-3t/
* Les Tests en Trois Temps (3T) en pratique : http://thierry-leriche-dessirier.dev...t-en-pratique/

Le premier est une introduction à 3T. Le second est une mise en condition sous forme d'un miniroman.

En outre, je conseille le très bon tutoriel de Bruno Irsier, à propos des TDD, sur developpez.com à l'adresse http://bruno-orsier.developpez.com/t...TDD/pentaminos

Pour les tests des bases de données. En plus de JUnit, j'utilise DbUnit qui permet notamment d'avoir des jeux de test, comme des bases de données, sous forme de fichiers XML. Ca fait beaucoup d'autres choses que je ne détaillerai pas ici.

Tu peux compléter avec des systèmes de simulacre comme EasyMock et/ou de mock comme Mockito. Pour cela, je te renvoie vers plusieurs articles :

* Easymock ou le bouchon royal : http://thierry.leriche-dessirier.com...o-easymock.htm
* Série de blog Spock (1/3) – Spock, JUnit et le Data Driven Testing : http://www.java-freelance.fr/java/sp...driven-testing
* Les erreurs courantes avec EasyMock : http://www.java-freelance.fr/java/le...-avec-easymock
* EasyMock – Techniques avancées : http://www.java-freelance.fr/java/ea...iques-avancees

J'espère que ça te donne des bonnes pistes. Il y a déjà un max de lecture là.

[romaintaz]

Bonjour Thierry,

Continuons notre petit débat

Le truc qui me gène le plus avec les TDD, c'est que les développeurs (et leurs chefs) ne savent pas vraiment par quel bout le prendre. Chacun voit midi à sa porte, ses propres contraintes et besoins, ses attentes personnelles, etc. L'idée de 3T, c'est de dire clairement comment faire les choses, dans quel ordre, qui fait quoi, etc.

Pour moi, le principal problème du TDD, en particulier pour les personnes ayant pas mal codé par le passé sans faire de TDD est le manque de rigueur, ou de bien de relâchement.
Faire du TDD, ou même "simplement" écrire des tests est contraignant : ce n'est pas simple (écrire des mocks, tester des choses difficilement testables, écrire du code testable même) et on est vite tenté de se décourager. Ou alors de se dire "bon, je fais du TDD, mais là, je suis un peu pressé alors je vais le faire 'à l'ancienne', et je reviendrais faire des tests plus tard" (sous-entendu je n'y reviendrais plus).
Là, je peux comprendre ton travail sur les 3T : tu essaies de créer un cadre plus strict, de façon à éviter justement cela, en donnant des tâches à chacun. L'idée derrière cela étant d'éviter que le développeur n'écrive pas les tests pour son code, puisque c'est une autre personne qui les écrira.
Reste que malgré tout, que ce soit avec 3T ou TDD, il faut que les développeurs adoptent une certaine discipline quand même, jusqu'à ce que cela devienne naturel...

Oui exactement. C'est un des points auquel je me suis attaché. Les TDD doivent permettre de réduire les coûts. Ils permettent de développer plus vite et avec une meilleure qualité. Le surcoût généré par l'écriture des tests doit normalement être contre balancé par la vitesse gagné sur la phase de développement du code de production et, surtout, sur les bugs évités.

On est d'accord. Il faut voir le développement des tests comme un investissement sur le moyen terme, et les "économies" faites sur le très court terme en zappant les tests se payent au prix fort par la suite.
Toutefois, je n'aime pas entendre le "surcoût généré par l'écriture des tests".
Ce que je veux dire par là, même si je sais que l'on en est encore loin aujourd'hui, c'est que normalement, l'écriture des tests fait partie de l'écriture du code, et ne devrait normalement pas être dissocié. Les tests sont là non seulement pour vérifier que le code écrit fait ce que l'on attend de lui, mais c'est aussi une aide précieuse au développeur pour savoir comment écrire son code. C'est un peu comme si l'on veut écrire un texte et qu'en plus, il faut aussi écrire un brouillon. Le brouillon fait partie du processus de l'écriture du texte, et donc ne devrait pas être compté à part.

Seulement, voilà, les "gars d'au dessus" ne comprennent pas ce genre de raisonnement. Le "gars d'au dessus", il voit les dépenses mais pas les gains. Il se dit seulement que les tests représente du temps de développement en plus sans voir le temps qu'on gagne sur le codage de production. Il se dit qu'il paye déjà très cher des prestataires experts et qu'il ne devrait pas avoir à financer leurs lubie pour les tests. Il se dit, souvent à juste titre, que ça va encore plus embrouiller les équipes. Bref, il n'a pas envie de payer pour ça.

Heureusement, je pense que les mentalités commencent à changer, parce que justement ils commencent à s'apercevoir que la maintenance et les corrections des applications en production coûtent cher. Du coup, ils commencent à s'intéresser à la qualité, même si c'est généralement trop tardivement, car là on parle plus d'ajouter des tests à du code legacy qu'à faire du vrai TDD. Mais j'ai espoir que les choses changent, mais cela ne viendra qu'avec l'insistance des développeurs eux-mêmes. Le chemin est encore bien long...

(...) La réponse a été de s'appuyer sur le cahier des charges. En effet, celui-ci (...) doit donc être parfait. En tous cas, puisque le chef me balance les spécifications dans la tronche, autant rebondir dessus.

Dommage de partir sur un principe faux. C'est rare un cahier des charges parfait

Dans un premier temps, un développeur (et non un fonctionnel) va recopier le cahier des charges sous forme d'interface. Ce sont des copié-collés relativement simples, qui ne coûtent donc pas cher. C'est presque un travail de grouillot... J'exagère mais vous comprenez l'idée. C'est gratos... Ca le chef, il aime toujours.

Gratuit ? J'imagine tout de même pas que le développeur va "juste" ouvrir Excel, faire une sélection et copier tout ça dans Eclipse. Sur ton exemple de Fibonacci peut-être (quoiqu'il faut formaliser son format Excel, ce que l'on peut faire quand on fait des tests d'acceptance avec FitNesse par exemple), mais dans de vrais projets, je pense que c'est tout de même plus compliqué que cela.
Et je doute qu'un travail, aussi court soit-il, soit un travail gratuit.

Ensuite, un autre développeur va écrire tous les tests de la fonctionnalité, d'un coup. Il s'appuie pour cela sur l'interface précédemment écrite. Il recopie les numéros des règles pour bien référencer les demandes.

Pour moi, c'est un peu le souci de ta méthode 3T. Certes, ce n'est pas bête de se dire que comme j'ai les specifications fonctionnelles, avoir des tests qui me permettent de les vérifier me permettra de savoir si j'ai bien fait ce que l'on attend de moi.
Mais ce n'est pas suffisant. Les tests unitaires ont au moins 2 buts :

• Vérifier que la méthode fait ce que l'on attend d'elle, et là 3T répond à peu près à ce point.
• Vérifier que la méthode se comporte correctement dans les cas "extrêmes", et là, les specifications fonctionnelles ne seront pas toujours à même d'y répondre, car il y a une vraie considération technique derrière cela.

Pour illustrer mon dernier point, et en reprennant ton sujet sur Fibonacci, un exemple de cas "extrême" serait de savoir ce qu'il se passe si je donne à ma fonction Fibonacci une valeur null. Pour un MOA, null n'a pas de signification fonctionnelle. Or, tout développeur a déjà été confronté à des NullPointerException. Ses fonctions doivent donc être capables de traiter ce genre de données (et encore, là mon exemple est simple). Et de mon point de vue, je n'ai pas vraiment l'impression que 3T, de par la séparation des tâches (écriture des tests et du code), puisse vraiment répondre à cette problèmatique.

L'idée, c'est surtout de mécaniser la partie que le chef n'a pas envie de payer.

Je ne vois toujours pas en quoi 3T est plus adapté. Le coût, comme tu l'as dit, n'est pas dans la recopie des spécifications dans Eclipse. Dans 3T, comme dans TDD, tu as tout de même l'écriture des tests à faire, et ça, que ce soit en 3T ou en TDD, ça ne change rien.
Donc où se trouve le gain concrètement ?

Avec 3T, le chef se dit que ça ne coûtera rien de plus, si ce n'est des copié-collés vite faits.

Voir ma réponse juste au dessus. C'est faux de dire cela ! Ecrire des tests, ça a un coût (sur le court terme, on y gagne énormément sur le long terme, on est d'accord). Le seul moyen de dire que cela ne coûte rien (toujours sur le court terme), c'est de ne pas faire de tests du tout. Et là, tu ne fais plus du 3T ou du TDD. Une autre possibilité, c'est que ton chef ne comprenne rien

Oui, dans tous les cas, il faut les coder. Le petit avantage avec 3T, c'est qu'on te dit directement comment les écrire, par qui, etc.

Avec 3T, on te dit quels tests écrire. Mais surement pas comment. Et c'est là la complexité du TDD / 3T.
Je me répète mais pour que ce soit bien clair : j'ai compris que 3T peut aider à formaliser un peu mieux les choses en affectant des responsables à chacune des tâches. Mais cela ne simplifie pas pour autant le processus de développement et ne réduit pas non plus le coût de l'écriture des tests...

En fait, dans 3T, l'idéal est que deux phases successives ne soient pas prises en charge par le même développeur. Comme ça, on évite les raccourcis, les tests de complaisances, les portions de code que seul la personne peut comprendre, etc. En partageant le travail, d'abord on simplifie chaque partie, ensuite on s'oblige à bien faire chaque partie, pour peu que l'équipe joue le jeu.

Pourquoi pas. Mais comme tu le dis, au final, il faut que l'équipe joue le jeu, car sans cela, même la plus précise ou cadrée des méthodes ne te fera pas réussir.

La première personne écrit une interface et une implémentation vide. Ca ne crée aucun problème de compilation. Il commit.

Jusque là, on est d'accord.

La seconde personne écrit des tests qui restent rouges. On n'a toujours pas de problème de compilation. Il commit.

Bah là, ça fait boum ! Ton code compile certes, mais tes tests sont en erreur. Tu as donc du code qui ne fonctionne pas qui est commité sur ton gestionnaire de sources (SCM).
Etant donné qu'avec 3T tu écrits tous les tests d'un coup, tu vas avoir plein de tests en échec, et il faudra attendre la fin du développement de ta fonctionnalité - ce qui peut prendre plusieurs jours - pour que tu retrouves du code sain sur ton SCM.
Et pour moi, ce n'est pas acceptable d'avoir un tel état. Car il faut bien penser que ton équipe de développement peut être étendue, et que tu as donc plusieurs fonctionnalités développées en parallèle.
Du coup, ça va vite être le capharnaüm quand tu as une dizaine de développeurs et une demi-douzaine de fonctionnalités en cours de développement.
L'idée principale de l'intégration continue est d'intégrer - de façon continue - une modification dans l'ensemble de ton application. Si le code que tu viens de commiter casse un test à l'autre bout de ton application, alors tu vas pouvoir réagir immédiatement pour corriger cela (vive les tests de non régression !).
Or, s'il y a 3 autres fonctionnalités en cours de développements, je ne pourrais pas savoir si le commit que je viens d'effectuer est correct, car j'aurais 25 tests qui échoueront, dûs aux choses non encore développées par mes collègues. Mais peut-être que dans le tas il y a un test qui vient d'échouer justement à cause de mon code commité à l'instant ? Je ne peux pas le savoir. Dommage !
Bref, avec ce principe, tu reviens quelques années en arrière, où tu vas devoir régler tes problèmes d'intégration à la fin de ton cycle...

Le chef a le cahier des charges sur son bureau. Et puis, souvent, le CP n'est un techos. C'est juste un manager qui gère des gens et des chiffres. Il s'appuie sur les données qu'il maîtrise.

Justement. Je pense qu'il préfèrera éviter d'aller regarder dans son cahier des charges pour voir à quoi correspond cette erreur. Le but d'un nommage correct du test est de le rendre compréhensible, y compris par un non techos (du moins d'expliquer ce que le test est censé tester).
Mais de toutes façons, je pense que le CP lui, il s'en fiche de savoir quel test échoue. Ce qui doit l'importer, c'est qu'aucun test n'échoue (cf. mon chapitre précédent). Si un test échoue, c'est plutôt la préoccupation du leader technique et tous les développeurs. Et eux seront bien contents d'avoir un test avec un nom parlant, surtout quand il porte sur une partie qu'ils ne connaissent pas forcément...

Je pense que la plupart des développeurs se concentrent malgré tout sur leur périmètre.

Mais la qualité et la réussite des tests fait partie intégrante de la qualité ! C'est comme si un constructeur de voitures faisait une voiture sans s'assurer qu'elle roule correctement, dans différentes conditions. C'est aussi cet état d'esprit qu'il faut combattre.
J'aime d'ailleurs beaucoup cette phrase :

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

(code toujours en pensant que la personne qui aura à maintenir ton code est un violent psychopathe qui connait ton adresse)

Disons un sonar associé à un hudson et plein de plugins divers

C'est un minimum vital pour tout projet, n'est-ce pas ?

Par exemple, si c'est dans du scrum, avec des unités de temps bien choisies, ça peut rendre bien. Mais là autant utiliser directement le burndown...

Bah oui, Scrum, s'il est bien utilisé est fait pour cela.
Malheureusement, on tombe trop souvent sur des fameuses méthodes agiles "ajustées" par les entreprises, pour que ces méthodes s'adaptent à leur façon de penser et de fonctionner. Au final, ces pratiques n'ont d'agile que le nom, et sans surprise amènent à l'échec. Et naturellement, la conclusion est que les méthodes agiles ne fonctionnent pas Mais c'est un autre sujet...

Là je suis preneur de toutes les bonnes idées pour mécaniser cette partie.

Peut-être que justement tout n'est pas à mécaniser. Les méthodes agiles essaient de se concentrer sur l'humain avant tout...

Je me suis rendu compte que le versionnement des règles, c'est vite le bazar.

Et pourquoi ? Après tout, si une règle évolue, c'est une évolution, pas forcément un big bang. Versionner, c'est surtout historiser, et donc avoir la possibilité de comprendre comment un test vie, évolue, et potentiellement de comprendre aussi pourquoi le code évolue. Je ne comprends pas ce point-là...

Si si, les tests sont du code. Ils font partie du livrable.

Donc ils devraient être versionnés

Bon ça fait une réponse super longue mais ça fait avancer le sujet.

Tout pareil !

[thierryler]

Merci pour toutes ces précisions. Je pense qu'on avance dans le bon sens. Un de mes prochains article sera justement un truc du style "Formalisation de la méthode 3T, les Tests en Trois Temps" et c'est clair que ça m'aide à discerner ce qui n'est pas clair, mais aussi ce qui n'est pas adapté.

Pour moi, le principal problème du TDD, en particulier pour les personnes ayant pas mal codé par le passé sans faire de TDD est le manque de rigueur, ou de bien de relâchement.

Oui. Et j'ajouterais la démotivation et/ou l’incompréhension.

Faire du TDD, ou même "simplement" écrire des tests est contraignant [..] Là, je peux comprendre ton travail sur les 3T : tu essaies de créer un cadre plus strict, de façon à éviter justement cela, en donnant des tâches à chacun. L'idée derrière cela étant d'éviter que le développeur n'écrive pas les tests pour son code, puisque c'est une autre personne qui les écrira.

L'idée principale est de fournir un cadre. Et je pense que la séparation des temps (réalisés par des personnes différentes) force à respecter les cadres.

Reste que malgré tout, que ce soit avec 3T ou TDD, il faut que les développeurs adoptent une certaine discipline quand même, jusqu'à ce que cela devienne naturel...

Oui. Même pour celui qui conçoit la méthode ;-)

Heureusement, je pense que les mentalités commencent à changer, parce que justement ils commencent à s'apercevoir que la maintenance et les corrections des applications en production coûtent cher. Du coup, ils commencent à s'intéresser à la qualité, même si c'est généralement trop tardivement, car là on parle plus d'ajouter des tests à du code legacy qu'à faire du vrai TDD. Mais j'ai espoir que les choses changent, mais cela ne viendra qu'avec l'insistance des développeurs eux-mêmes. Le chemin est encore bien long...

Je ne suis pas si certain. J'en discutait justement hier soir avec un ami, directeur de projet dans une très grosse SSII internationale. Il m'expliquait très clairement qu'il n'en avait rien à faire des tests. Ce qui compte c'est le fric. fric. fric. La qualité, oui, ça lui parle. Mais il préfère écrire les bons tests, un peu comme avec 3T à Paris, et laisser le code à sa tribu d'indiens... Je vous passe les détails de la discussion, pleine d'enseignements.

Avec 3T, une de mes cibles est justement les DP qu'il faut convaincre. Et pour cela, ça passe forcément par le porte monnaie.

Dommage de partir sur un principe faux. C'est rare un cahier des charges parfait

Oui et 3T recommande de faire des aller-retours en complétant les spécifications (ça peut être le redmine par exemple)

Gratuit ? J'imagine tout de même pas que le développeur va "juste" ouvrir Excel, faire une sélection et copier tout ça dans Eclipse. Sur ton exemple de Fibonacci peut-être (quoiqu'il faut formaliser son format Excel, ce que l'on peut faire quand on fait des tests d'acceptance avec FitNesse par exemple), mais dans de vrais projets, je pense que c'est tout de même plus compliqué que cela.
Et je doute qu'un travail, aussi court soit-il, soit un travail gratuit.

Rien n'est jamais vraiment gratuit. Si tu prends l'exemple de Fibonacci, c'est pourtant quasi des copié-collés pour avoir une première passe. Il faudra évidement un peu de temps encore pour les tests complémentaires, et les trous dans le cahier des charges. Toutefois je peux facturer ces trous en "analyse et correction des spécifications" au lieu de les passer en "codage", du coup, c'est effectivement gratuit. Si les CP aiment jouer au cons avec leurs lignes comptables, ça leur donne des cartouches.

Vérifier que la méthode se comporte correctement dans les cas "extrêmes", et là, les specifications fonctionnelles ne seront pas toujours à même d'y répondre, car il y a une vraie considération technique derrière cela.

Effectivement, j'ai zappé cette partie, comme c'était un article de la série "en 5 minutes". Par contre j'aborde ce point dans les autres articles. Dans le miniroman par exemple, cela donne des post-it technique (orange je crois) qui donnent lieu à des tests.

Je ne vois toujours pas en quoi 3T est plus adapté. Le coût, comme tu l'as dit, n'est pas dans la recopie des spécifications dans Eclipse. Dans 3T, comme dans TDD, tu as tout de même l'écriture des tests à faire, et ça, que ce soit en 3T ou en TDD, ça ne change rien.

Je pense qu'il y a un petit gain dans la mesure où 3T te dit que tu dois tester chaque règle. une par une. Avec AAA, etc. Ca évite de partir dans tous les sens.

Sur un ancien projet, le CP nous avait demandé de faire des tests d'un Web Service mais on n'a jamais vraiment réussi à comprendre ce qu'il attendait et ça a traîné en longueur. On n'a jamais pu se mettre d'accord sur un format. etc. Et le CP, de toutes manières, il ne savait pas non plus LOL

Mais comme tu le dis, au final, il faut que l'équipe joue le jeu, car sans cela, même la plus précise ou cadrée des méthodes ne te fera pas réussir.

Oui. Evidemment. C'est d'ailleurs un des points que j'essaie de mettre en évidence dans les discussions dans les annexes du miniroman sur 3T. Si les règles du jeu sont trop complexes ou pas assez cadrées, on risque de se perdre ou/et de se démotiver.

Petite digression : Les Echecs ou le Go, tu peux apprendre les règles en 10 minutes. Il te faudra des années avant d'être bon mais tu peux t'amuser tout de suite. Par contre, Donjon et Dragon, ou même Risk, je n'ai jamais été bien loin. Trop long. Trop de choses à voir dès le début, etc.

Bah là, ça fait boum ! Ton code compile certes, mais tes tests sont en erreur. Tu as donc du code qui ne fonctionne pas qui est commité sur ton gestionnaire de sources (SCM). [..]

Ok je n'avais pas compris ton point. Oui c'est très juste. Dans le second article sur 3T, avec plein de post-it et de gomettes, ce n'était pas trop gênant puisque le périmètre du sprint permettait de "réguler" cet aspect. Mais effectivement, c'est un point faible de 3T. Toutefois, tu préfères avoir des tests en rouges qui indiquent qu'une fonctionnalité est incomplète ou des tests verts qui masquent que tout n'est pas encore fait. Perso, je préfère que mon code plante à cause du code du voisin avec un beau message d'erreur qu'avoir un code qui plante sans savoir pourquoi, m'obligeant à aller voir le mec après analyse.

Justement. Je pense qu'il préfèrera éviter d'aller regarder dans son cahier des charges pour voir à quoi correspond cette erreur. Le but d'un nommage correct du test est de le rendre compréhensible, y compris par un non techos (du moins d'expliquer ce que le test est censé tester).

Ca doit dépendre du CP alors. Faut penser qu'avec la multiplication des tests, c'est aussi assez dur d'avoir des méthodes avec des noms différents.

Que penses-tu du compromis suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public void testFibonacciOf3Is5_RG123_a() {
  ...
}

code toujours en pensant que la personne qui aura à maintenir ton code est un violent psychopathe qui connait ton adresse

Bonne citation. Je vais la retenir pour plus tard : code en sachant que Thierry sait où tu habites LOL

C'est un minimum vital pour tout projet, n'est-ce pas ?

Heu... Comment dire ?... Quand je suis arrivé sur ma mission actuelle, par exemple, je n'ai trouvé que [..] Netbeans... Ni Hudson, ni JUnit, ni rien. rien. rien. rien. D'ailleurs ça faisait un an que l'application était en développement et loin d'être finie. Pleine de bugs avant même la livraison du premier lot. Et zéro visibilité. Et ce n'est pas un cas isolé.

Et pourquoi ? Après tout, si une règle évolue, c'est une évolution, pas forcément un big bang. Versionner, c'est surtout historiser, et donc avoir la possibilité de comprendre comment un test vie, évolue, et potentiellement de comprendre aussi pourquoi le code évolue. Je ne comprends pas ce point-là...

Parce qu'on a toujours des développeurs en retard ou en vacances qui ne travaillent pas forcément avec la dernière version des spécifications, ou qui ont imprimé le mauvais fichier, etc. J'ai ainsi travaillé sur des projets où les développeurs utilisaient 3 versions différentes du cahier des charges. Et là je ne parle même pas de la MOA (et encore moins du CP trisomique)

Donc ils devraient être versionnés

Ok on ne parlait pas de la même chose je pense. Oui les tests sont bien versionnés. Par contre, quand on règle change, je crée une nouvelle règle (ie. un nouveau post-it) et une nouvelle méthode dans ma classe de test. L'ancienne méthode est supprimée.

[Luckyluke34]

Dommage de partir sur un principe faux. C'est rare un cahier des charges parfait

+1000

J'avais fait un peu les mêmes réserves lorsque Thierry avait publié l'article précédent, bien que je trouve la méthode intéressante : http://www.developpez.net/forums/d11...n/#post6316304

[thierryler]

Le cahier des charges n'est jamais parfait. Sur les articles précédents, j'utilisait carrément des post-it. Toutefois si l'équipe joue le jeu et complète le jeu de post-it, on peut dire que le cahier des charges monte d'un cran vers la perfection ;-) Bon soyons honnêtes, on n'aura jamais un cahier des charges parfait. On peut juste essayer de faire de notre mieux, sous réserve que l'équipe joue le jeu.

[romaintaz]

Je voudrais rajouter deux choses concernant l'intégration continue et les tests :

1. Je dis que c'est le minimum vital pour un projet car cela ne coûte (presque ) rien à mettre en place (surtout le couple Jenkins + Sonar), et cela apporte un gain absolument pas négligeable dans le cycle de développement. Ce n'est malheureusement pas le cas partout je le reconnais, et quand bien même ces briques élémentaires existent, elles restent souvent mal ou sous-exploitées. J'en sais quelque chose, car j'ai passé une bonne partie de l'année précédente à mettre une IC aux petits oignons sur un gros projet (IC au sens large : Jenkins + Sonar, mais aussi les pratiques associées, les releases et déploiements automatisés, l'amélioration des tests, etc.). Et maintenant, je recommence à peu près la même chose sur d'autres projets ...

2. Concernant l'histoire des tests qui ne compilent pas, pour moi c'est un vrai problème. Mais heureusement, j'ai une suggestion à te faire qui ne te coûtera rien (enfin presque rien ). Afin de ne pas chambouler tes principes, en particulier l'écriture de l'ensemble des tests unitaires d'un coup, pourquoi ne pas faire ignorer ou catégoriser ces nouveaux tests ? La 2e option étant d'ailleurs bien meilleure. Cela ne coûte qu'une annotation Java, et ça va changer ta vie.

Explications.

Considérons ces 2 tests unitaires :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
@Test
public void un_test_termine() {
    ...
}

@Test
@Category(NotYetImplemented.class)
public void un_nouveau_test() {
    ...
}

Le premier test est un test qui est au vert, car sa fonctionnalité est développée. Le second test est au rouge, car le développeur n'a pas encore travaillé dessus. Pour indiquer cet état, on va annoter le test avec @Category(NotYetImplemented.class) (NotYetImplemented est une simple interface pour catégoriser des tests, rien de plus). TestNG (si tu le préfères à JUnit) dispose aussi de cette fonctionnalité de catégorisation (son annotation prend une String plutôt qu'une interface, mais ça reste identique sinon).

Ensuite, tu configures le plugin Surefire de Maven pour qu'il exécute ou non les tests non implémentés (i.e. annotés avec la catégorie). L'idéal serait d'avoir 2 profils Maven :

• build standard : ne lance aucun test annoté avec cette catégorie.
• build complet : lance tous les tests.

Du coup, sur ton serveur d'intégration continue, tu crées 2 jobs :

• le job standard : si une erreur apparait, c'est qu'il y a une régression, car tous les tests doivent passer, et il doit donc être corrigé ! Ici, 100% des tests doivent passer dans ce build et c'est non négociable.
• le job d'avancement : ici, les erreurs sont acceptées, car elles indiquent (dans une certaine mesure) le degré d'avancement des fonctionnalités.

Grâce à cela, tu as un build (le job standard) qui te permet de vérifier en permance que le code existant est fonctionnel.


C'est'y pas magique ?


Pour info, voici à quoi ressemblerait le pom :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
    <build>
        ...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <!-- Il faut au moins la version 2.11 de surefire pour pouvoir gérer les groups avec JUnit... -->
            <version>2.12</version>
            <!-- Il y a un bug dans la version 2.12 de surefire (corrigé en 2.13),
                qui oblige à définir le provider afin de pouvoir utiliser la configuration des <groups> -->
            <dependencies>
                <dependency>
                    <groupId>org.apache.maven.surefire</groupId>
                    <artifactId>surefire-junit47</artifactId>
                    <version>2.12</version>
                </dependency>
            </dependencies>
        </plugin>
    </build>
 
    <profiles>
        <profile>
            <!-- Le build standard, où l'on va exclure les tests annotés... -->
            <id>standard</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <configuration>
                            <excludedGroups>mon.project.NotYetImplemented</excludedGroups>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
 
        <profile>
            <id></id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <configuration>
                            <!-- On demande à surefire de jouer les tests annotés.
                                A voir s'il ne faudrait pas aussi lui demander de lancer les autres tests, ou si c'est automatique ? -->
 
                            <groups>mon.project.NotYetImplemented</groups>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

Bon, ce n'est pas forcément exactement cela, car je ne suis pas sûr qu'il va intégrer aussi les tests non catégorisés (à tester donc). Il va falloir peut-être un peu bidouiller le pom, ou alors être obligé d'annoter aussi les tests une fois finalisés, mais avec une autre annotation bien sûr

[thierryler]

Oh la la

Je dis que c'est le minimum vital pour un projet car cela ne coûte [..]

On est en train d'en monter une avec les moyens du bord à mon bureau. C'est pas simple, surtout quand on est pas spécialiste...

j'ai une suggestion à te faire qui ne te coûtera rien [..] Grâce à cela, tu as un build (le job standard) qui te permet de vérifier en permance que le code existant est fonctionnel.

Magnifique !...

J'avais cherché une solution de ce genre sans réussir à trouver un truc bien. Faut que je vois comment intégrer ça. Comme quoi ça vaut le coup de partager avec des spécialistes de l'IC.

[romaintaz]

Content que ça puisse t'être utile. Comme tu peux le voir, c'est très simple désormais de catégoriser ses tests avec JUnit et Surefire.

JUnit a introduit tardivement (surtout comparé à TestNG) les catégories (JUnit 4.8 de mémoire), et l'a introduit d'une façon assez déplaisante. Il suffit de voir tout ce qu'il faut faire normalement sur cet exemple :
http://weblogs.java.net/blog/johnsma...t-categories-0

Mon principal grieff étant de définir en plus des catégories une Suite qui listera les classes de tests à intégrer dans la catégorie. Du coup, si tu ne maintiens pas ta suite à jour, il est possible d'oublier des nouvelles classes de tests.

Pour éviter cela, dans mon application, j'avais créé une mini-librairie pour catégoriser les tests avec une annotation, et qu'ensuite, ce soit Maven et mon propre Runner JUnit qui partent à la recherche des classes annotées. Ma solution, pas parfaite mais qui fonctionne, est expliquée en détails ici :

http://linsolas.free.fr/wordpress/in...it-avec-maven/

Mais tout cela est désormais obsolète, car Surefire 2.11 a permis d'utiliser les <groups> directement, sans plus avoir à définir son propre Runner et sa Suite. C'est ce que j'ai expliqué dans mon précédent post.