Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui, je réponds à la question de Julien Jett.
Qu'est-il pertinent de tester dans sa code base ?
Tu te poses aussi la question, tu me dis du TDD,
mais est-ce que je dois le mettre en oeuvre de manière systématique ?
Est-ce que tu me dis aussi le TDD requiert de tester 100% du code ?
Je pense Julien que tu abordes la question de travers, je crois.
Qu'est-il pertinent de tester dans sa code base ?
Pour moi, si je suis en TDD, la question ne se pose pas.
Le TDD, ce n'est pas une question de test.
Le fait d'avoir une batterie de tests automatisé
est presque un deuxième effet qui se coule, c'est presque un effet secondaire.
Je dis presque parce que évidemment, ça rentre dans la dynamique du TDD,
mais ce n'est pas l'intention première.
L'intention première du TDD, c'est une démarche.
Je fixe un objectif et je vois comment je m'approche de cet objectif.
On est là complètement au cœur d'une approche empirique,
c'est-à-dire je définis la prochaine étape et je fais des pas,
alors plus ou moins grand des petits pas ou des grands pas, vers mon objectif.
Mais ce n'est pas une question de test.
Tu m'interroges aussi sur le compromis entre la solidité du code
et rapidité, agilité de développement.
Comme s'il y avait un choix à faire entre aller vite ou faire du code propre.
Pour moi, ce n'est pas tellement une question de compromis.
J'ai peur que si tu l'abords sous cet angle,
on ne parle pas en fait de compromis mais de compromissions.
Pour moi, soit tu fais du TDD, soit tu n'en fais pas.
Et ne pas faire du TDD, ben d'un absolu, c'est pas dramatique.
Bah je ne sais pas, soit tu en fais, soit tu en fais pas.
Si tu en fais, tu ne te poses pas toutes ces questions.
Et si tu te poses toutes ces questions, c'est que tu n'as pas encore eu le déclic du TDD.
Mais ce n'est pas grave, ça viendra.
Moi, il y a des moments où je ne suis pas en TDD.
Je te donne un exemple de quelque chose sur lequel je ne travaille pas en TDD.
Ça va être vraiment ce qui concerne la couche la plus extérieure,
la plus superficielle de mon application dans les vues.
Je suis sur une stack Ruby on Rails et mes vues sont très très très légères.
J'ai quasiment que du HTML, quasiment que ça.
J'ai un tout petit peu de JavaScript, il y a encore, c'est du côté front.
Donc je te donne un exemple sur un gros projet récent sur lequel j'ai bossé.
Bah le bac n'est pas en TDD, je n'ai pas de cucumber qui passe sur le bac.
Pourquoi ? Parce que j'ai fait un arbitrage là effectivement,
de dire finalement cette partie bac, les tests Antoine vont être assez lent,
il n'y a que nous qui l'utilisons.
Je me passe de la non-régression, c'est pas très grave,
et le TDD sur cette partie qui est très extérieure, c'est-à-dire vraiment que la vue, je m'en passe.
Par contre, attention, tous les contrôleurs sont testés extensivement,
tous les modèles sont testés extensivement, tous les modèles sont testés extensivement,
tout le reste en dessous est testé à fond, à plus de 98% de couverture de code.
Donc il y a des endroits, des petits morceaux,
ou effectivement je ne suis pas systématiquement en approche TDD.
Mais si tu dis je fais du TDD, cette question de compromis ne se pose pas.
À un moment aussi tu parles des tests de Shulda.
Alors en rubi, il faut réaliser une chose, c'est que tu es dans un langage typeé dynamiquement.
Il y a des choses que tu ne peux pas exprimer, comme tu pourrais l'exprimer avec un langage typeé statiquement.
Je te donne un exemple, si tu veux que ta classe, enfin pas érite mais définisse une interface,
implément une interface, c'est pas si facile que ça à exprimer.
En tout cas, tu ne peux pas l'exprimer dans l'objet de manière intrinsèque au langage.
Donc les tests à ce moment-là jouent en rôle de documentation.
C'est toujours le cas, les tests jouent en rôle de documentation,
mais c'est particulièrement vrai dans ce langage,
où certaines choses ne peuvent pas être exprimées au travers du langage lui-même.
Après tu me parles des tests que tu vois parfois comme un boulet.
Alors c'est clair que si tu perçois ta batterie test comme quelque chose de lourd et pénible,
tu as un souci.
Tu as un souci parce que si c'est ennuyeux, si c'est embêtant,
si tu as l'impression d'être ralenti,
tu risques à un moment donné de ne plus avoir envie de les mettre à jour.
Et à un moment donné, le gros risque c'est de laisser pérécliter la batterie test.
C'est-à-dire que tu commences à avoir une batterie qui passe en rouge dans l'intégration continue.
Et puis en fait tu dis c'est bon je m'en occuperai demain,
ou c'est pas très grave.
Donc là il y a un danger sur ça.
Après, si tu as l'impression que parfois ces contrôles qui sont faits t'alourdissent
et que tu préférais être plus léger, je peux te dire oui, tu sais en escalade c'est un peu pareil.
Tu perds vachement de temps à accrocher les pitons et accrocher ta corde,
jusqu'au jour où tu tombes.
Si c'est lent, c'est un peu le même principe.
C'est vrai que rapidement, surtout en RuneMillion Rails,
avec si on s'appuie sur l'active record et si on s'appuie sur le frame recrails pour écrire ses tests,
les tests peuvent prendre un certain temps, il faut le reconnaître.
Moi sur des grosses pas de tritest, je suis à 2-3 minutes pour renais l'ensemble.
Il y a des jours où c'est pénible, je reconnais, c'est un peu fatiguant.
Là je t'invite à jeter un oeil sur, il y a plein d'optimisation possible, soit,
tu cherches à paralléliser les choses, soit, tu t'orientes vers des architectures hexagonales.
Je t'avoue que personnellement, j'en suis resté là pour l'instant,
mais je suis bien du côté des archers hexagonales qui me font de l'œil.
Enfin tu me demandes, est-ce que la valeur ajoutée vaut le coup ?
C'est-à-dire, est-ce que le prix que ça coûte d'écrire ses tests, d'être dans cette démarche,
vaut le coup de la mise en œuvre ?
Alors si tu utilises le TDD comme un outil de pilotage,
pour moi, très clairement, la question ne se pose même pas en fait.
Or, mais il fait que la réponse soit oui,
puisque pour moi, au-delà d'un projet qui fait plus d'une heure de travail, c'est rentable.
Bon, après, chacun sa manière de voir les choses.
Après, ce qui est vrai, c'est que dans le coup, ça dépend de ce que tu y inclus.
Est-ce que tu y inclus le coup de la mise en œuvre uniquement
ou est-ce que tu y inclus le coup de la formation ?
Alors si tu dois te former en même temps, effectivement,
ça va peut-être repousser la durée de retour sur investissement à un peu plus d'une heure.
Mais sur un projet de moyen terme,
ne serait-ce que de quelques mois, je suis convaincu, que de se former assez pratique et rentable.
Après, si tu abordes les tests dans une logique de non-régression,
alors là, effectivement, à toi de mesurer l'impact.
Après, c'est une question de compromis.
C'est qu'est-ce qui se passe ?
Quel est le coup de mettre à jour une batterie de tests de non-régression
versus quel est le coup du si un risque de défaillance est avéré et se produit ?
Ce ne sera pas la même chose si tu es en train de lancer des fusées,
où le coût se chiffre en dizaines de millions de dollars sur un cas d'échec,
ou si tu es en train de lancer un prototype et que tu as cinq utilisateurs dessus.
Voilà pour aujourd'hui, j'espère avoir répondu à tes questions, Julien.
Quant à toi, chère auditeur, cette histoire m'a donné l'idée de créer une nouvelle rubrique.
Ce serait la rubrique de vos questions.
Donc si toi aussi, tu as envie, tu as une question que tu te poses, tu as envie que j'y réponde,
tu me l'écris à benoîtarobaseartisandeveloper.fr
et je verrai comment je peux y répondre dans un épisode.
Alors si tu veux que ce soit un épisode sympa,
l'idée c'est d'être le plus spécifique sur les questions que tu peux écrire,
de me donner un peu des éléments de contexte.
Si tu m'en vois juste un sujet,
ça va être un petit peu compliqué pour moi de comprendre comment orienter ma réponse.
Et je risque de taper à côté de la plaque.
Je te remercie et je te dis à demain.