Bienvenue sur le podcast Hortison développeur, l'émission pour les développeurs passionnés
qui combinent technique, agilité et développement personnel dans le but de nourrir l'excellence.
J'en entends souvent qui me disent à nous, Benoît, on n'a pas le temps d'écrire des
tests.
Tu comprends le projet sur des charboires ? Non, on n'a pas le temps.
Ou alors j'en entends qui sont carrément suicidaires et qui demandent à leur management.
Et, vous voulez des tests ou pas des tests ? Si vous posez cette question, vous aurez toujours
la même réponse.
Si vous donnez l'impression que les tests coûtent plus cher, ben évidemment que le
donné ordre, il va prendre sans les tests.
Puisque lui de toute façon, il considère que le boulot sera fait, bien fait et que ça
marchera.
Écrire des tests automatiques, c'est pas du ressort du client, c'est du ressort du développeur,
c'est du ressort de la manière de fabriquer.
Est-ce que Renault vous demande comment fabriquer sa voiture ? Non, il le fait.
Vous achetez une voiture qui roule.
Reprenons l'argumentaire de « ça prend du temps ».
Ah oui, tu te rends compte Benoît, il faut écrire des tests, il faut écrire du code
en plus.
Et puis, ce code à écrire, il prend du temps ? Oui, c'est vrai, le code de test à écrire
prend du temps.
Maintenant, est-ce qu'il prend du temps en plus ?
Je crois pas.
Je crois pas parce que si tu regardes bien quand tu écris des tests automatiques, quand tu
travailles en TDD, tu vas écrire moins de codes, facilement moins de la moitié de
codes que ce que tu aurais écrits normalement.
Et donc ça en fait déjà, rien que ça, ça compense le coût d'écriture des tests.
Mais c'est pas tout.
Combien de temps est-ce que tu passes sur ton debugger si t'y as pas des tests automatiques ?
Combien de temps tu passes sur ton navigateur ou sur ton mobile ou ton simulateur à tester
le truc que tu es en train de faire ?
Refléchis bien à ça parce que tout ce temps là, moi je pense qu'il représente au moins
50 à 60% de ton temps d'heuve.
Et bien imagine que tout ce temps là, tu l'enlèves.
À plus.
Plus de debug.
Plus de debug puisque ça casse plus.
Plus ce temps que tu passes à tester manuellement puisque c'est des tests automatiques qu'ils
le font.
Bon, ce temps là il est toujours là mais vachement réduit puisque c'est un automat au lieu d'un
être humain qui clique.
En fait, pas des tests automatiques ne prennent pas plus de temps.
J'ai deux fois la question à benoît au bout de combien de temps, quel est l'enveloppe
du projet, quelle est l'amplitude du projet qui justifie de faire des tests automatiques
ou des questions du genre est-ce que c'est un investissement à moyen terme, à long
terme ?
Non les mecs, TDD test automatique c'est un investissement à retour sur investissement
immédiat.
Tout de suite là maintenant, je gagne du temps tout de suite.
Par contre, ça prend du temps à maîtriser.
On est d'accord.
Comment exprimer un test ? Comment traduire l'intention qu'on a derrière ? Comment ne
serait-ce qu'adopter la logique TDD ? Est-ce que comprendre TDD ça met cinq minutes ? Mais
savoir le mettre en œuvre c'est des mois de travail ? C'est des mois de travail quotidien ?
Tout ça oui, apprendre à utiliser les tests auto et le TDD ça prend du temps.
Prend du temps à maîtriser.
Donc en fait quand tu dis « j'ai pas le temps d'écrire des tests », en fait tu dis « je
sais pas faire ». C'est pas grave, il faut juste apprendre.
Si la marche d'escalier est trop haute commence par faire du clean code, ce sera déjà un
excellent début.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
Si ce n'est pas déjà fait, viens t'inscrire sur artisan-developer.com et je te dis à
demain.