Le refactoring c’est tout le temps, et c’est normal. (épisode 5 - un nouvel espoir)
Charlotte est très attentive.
« Charlotte, comment vas-tu tester ? »
Déconcentration totale : Charlotte ne comprend pas pourquoi Marc pose cette question.
« Je ne sais pas encore.
— Tu dois le savoir maintenant. »
Charlotte a du mal à rester concentrée.
« Marc, d’abord nous codons. Après, nous testons.
— Non, coder, ce n’est pas un travail à la chaîne. Coder nécessite beaucoup d’allers retours pendant le développement. Ton mail, tu l’as écrit en une fois ?
— Non, Marc, mon mail, je ne l’ai pas écrit en une fois.
— C’est ça. À chaque fois que tu le modifiais, tu le testais. Tester permet de construire. »
Charlotte est au bord de la rupture, elle envisage une reconversion. Marc lâche le clavier, il voit qu’il la perd.
« Charlotte, je t’ai dit que je te montrerai, je te montre. Tu vas comprendre, c’est toi qui fais.
« Je répète : comment vas-tu tester cette nouvelle fonction qui va permettre à ton utilisateur d’éviter les déductions ? »
Charlotte accepte la question, elle veut comprendre.
« Je vais tester … trois choses :
- Que les propositions de la leçon soient les kanas de la leçon.
- Que la bonne réponse soit présente dans les propositions de la leçon.
- Que la bonne réponse ne soit pas présente dans les propositions de la leçon.
— Commençons par le premier test. Ecris le libellé du test.
— D’accord : les propositions de la leçon devraient être les kanas de la leçon. Ah ! Mais une fonction que j’ai codée le fait déjà, pas la peine d’écrire le test !
— Quelle fonction ?
— Eh bien la fonction de niveau normal propose déjà les kanas de la leçon lancée plus ceux des leçons précédentes.
— Premièrement, sois plus précise, modifie le titre s’il te plait : les propositions de la leçon difficile devraient être les kanas de la leçon normale. Deuxièmement, tu me dis que le test existe déjà ?
— Non, mais le code oui.
— Charlotte, tu me dis que ce n’est pas la peine d’écrire un test qui n’existe pas d’une fonction qui existe. Autrement dit, rassurez-vous messieurs-mesdames les utilisateurs, je n’ai pas testé mais ça marche.
— … j’ai testé en jouant avec l’application, ça compte, non ?
— C’est déjà ça. Tu as joué combien de tests ? Comment pouvons-nous savoir si les tests que tu as joués sont suffisants ? Ils faisaient quoi exactement ces tests ? Tu peux les refaire là, maintenant ?
— … je ne sais plus exactement.
— Alors écrivons le test, comme ça nous serons sûrs de ce que nous testons. »
Charlotte réfléchit, elle a l’intuition que Marc est peut-être en train de proposer de coller les kaplas. Il veut coller les kaplas pendant qu’il construit la tour.
« Charlotte, écrivons le test les propositions de la leçon difficile devraient être les kanas de la leçon normale. Qu’est ce que ce test reçoit en entrée ?
— Le test reçoit la leçon ka-ki-ku-ke-ko et les propositions a-i-u-e-o-ka-ki-ku-ke-ko.
— Que doit-il afficher en sortie ?
— Vrai. C’est la bonne liste de propositions de kanas à deviner pour cette leçon difficile.
— D’accord. Écris la fonction de test. Maintenant autre chose, comment doit s’appeler la fonction qui va être testée ?
— Alors, nous allons dire : kanaAAfficherPourLeçonDifficile, mais je ne l’ai pas encore développée !
— Normal, crée la fonction mais ne la développe pas. Et comme elle n’est pas vraiment créée, fais lui renvoyer Faux. Maintenant le test est complet, lance-le. Que dit-il ?
— Ben, il dit Faux. C’est normal hein car nous n’avons pas codé la fonction kanaAAfficherPourLeçonDifficile.
— Effectivement, nous l’avons appelée dans le test et nous ne l’avons pas codée. Codons maintenant cette fonction de la manière la plus simple possible.
— Même si c’est mal écrit ?
— Même si c’est mal écrit.
— D’accord, … voilà.
— Relance le test. Maintenant que dit il ?
— Vrai.
— Nous avons maintenant la fonction et son test. Et le code marche. Regarde à nouveau la fonction. Tu la trouves comment ?
— Pas très jolie, je peux réutiliser une fonction existante et enlever un paramètre.
— Une action seulement, commence par la première. Relance le test pour vérifier que le code marche toujours. Qu’en dis tu maintenant ?
— Je peux enlever un paramètre.
— Vas y, le test est toujours vert ? Ok. Et maintenant ?
— C’est mieux. Je peux encore renommer des variables.
— Ok, n’oublie pas de relancer le test. Et maintenant ?
— Ça va. »
C’était mal écrit, mais ça marchait. Elle a émis des feedbacks et elle a itéré. C’est mieux. Tiens, ça lui rappelle quelque chose.
Marc est tout souriant.
« Charlotte, nous avons codé un test que nous avons pu lancer trois fois instantanément, et grâce à ce test, nous avons refactoré notre code trois fois sans nous inquiéter de tout casser. »
Charlotte est épatée par un point : ce n’était pas dur.
L'exercice intellectuel d'écriture et de réécriture du code était plus facile que lorsqu’elle écrit du code sans test : le code a été écrit comme une réponse à l’écriture du test.
Elle compare son code précédent et celui-ci, et, indéniablement, le résultat est meilleur.
Elle en est contente.
« Ce n’est pas de la sur-qualité ?
— Tester tu veux dire ?
— Pas que tester, tout le process que tu m’as montré :
- Ecrire des tests avant de coder,
- coder,
- refactorer,
- recommencer.
— Tu le trouves comment ton code comme ça ? »
Charlotte repense à toutes les remarques de Marc quand il a lu son code la première fois.
« Mieux. Et tu fais tout le temps ça ?
— Oui.
— Et ça marche tout le temps ?
— Oui. Tu n’auras plus besoin de regarder méticuleusement ton code pour savoir ce qui ne marche pas. Imagine que tu fais ça tout le temps. Le débuggage consistera à regarder quel test ne passe pas. Imagine le nombre de tests que tu auras si tu en as environ trois par fonction, que tu peux lancer immédiatement. Tu n’auras plus peur de rien. Si tu as de meilleures idées tu pourras modifier ton code à ta guise, et le remanier. Ton code deviendra de plus en plus robuste. »
Charlotte est admirative.
« Marc colle les kaplas.
« Marc construit des tours solides. »
épisodes :
5 - un nouvel espoir