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é.
Citation:
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.
Citation:
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.
Citation:
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 ;-)
Citation:
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.
Citation:
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)
Citation:
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.
Citation:
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.
Citation:
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
Citation:
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.
Citation:
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.
Citation:
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:
1 2 3 4
|
public void testFibonacciOf3Is5_RG123_a() {
...
} |
Citation:
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
Citation:
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é.
Citation:
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)
Citation:
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.