Bienvenue sur le podcast Artisan Developer,
l'émission dédiée au programmeur qui parle de techniques, bien sûr,
de codes durables, mais aussi du métier en lui-même,
de recrutement, de développement personnel,
ou encore d'entrepreneuriat pour t'accompagner
dans une vie de développeur épanouissante.
Alors, est-tu prêt à passer au niveau supérieur ?
C'est parti !
Ce n'est pas parce que tu sais coder que tu sais écrire des tests.
Je sais que c'est quelque chose qui est assez difficile à comprendre,
mais en fait, c'est sur ça que principalement,
les gens qui veulent passer aux TDD butent le plus souvent.
De la même manière que si je te dis,
ok, tu sais coder, tu sais écrire un morceau de code,
c'est pas ça qui va te rendre capable d'écrire un programme entier.
Là, je pense que ça, ça va te parler.
C'est un petit peu comme le maçon,
on ne sait pas parce qu'il sait monter un mur,
qu'il va savoir construire une maison ou un immeuble ou une cathédrale.
Donc, tu as cette idée que coder, c'est vraiment la compétence, on va dire,
qui rejoint la notion d'écrire du code,
c'est-à-dire de traduire un moment donné quelque chose que tu veux faire en code.
Mais ce n'est pas pour autant que tu vas savoir forcément développer à large échelle.
Eh bien, les tests, c'est un petit peu pareil.
Et là, où c'est perturbant, c'est que les tests s'écrivent avec du code aussi.
Donc, quand tu es en Java, tu utilises les Units,
tu écris tes tests avec du langage qui est du Java.
Et donc, on pourrait croire que puisque tu sais coder, tu sais écrire tes tests.
Eh bien non.
Écrire un test auto, c'est traduire une intention à un moment donné,
c'est traduire un fonctionnement, c'est d'écrire comment ma classe, ma méthode,
mon package doit se comporter.
Et ça, donc ça traduit cette intention-là, et bien il faut savoir l'exprimer.
Ça demande vraiment un savoir-faire qui est particulier.
Et encore une fois, je reviens là-dessus, c'est sur ça que butent pas mal de gens.
Les gens me demandent, ah mais je sais pas quoi tester,
je sais pas par où commencer.
Et c'est assez difficile pour moi encore d'arriver à expliquer ça,
parce qu'en fait, j'ai envie de leur dire à ces gens-là.
Mais c'est facile.
Si tu as envie de faire quelque chose,
si tu bêtes simplement le test, tu traduis ton intention.
Tu as envie que ta classe, quand tu lui donnes deux paramètres,
en face, te rende un troisième,
ce qui est le cas le plus évident, le plus simple.
Eh bien c'est simple, tu écris un test que quand tu appelles
tel méthode avec tel paramètre, ça te retourne telle réponse.
Et là où ça devient un petit peu plus compliqué,
c'est dès que la réponse attendue ne s'exprime pas forcément
par une réponse directe.
Ah oui, mais là, cette méthode, elle fait des choses.
Ben oui justement, appuie-toi sur les conséquences de ce que fait cette méthode.
Cette méthode, si tu la connais, c'est qu'elle fait des choses.
Donc, viens chercher dans les impacts qu'a cette méthode,
et traduis sous forme d'attente, d'expectations,
ce que tu attends que face cette méthode.
Et ça, c'est vraiment quelque chose qui est compliqué à faire,
qui n'est pas du tout intuitif, en tout cas pas les premières fois.
Et donc là-dessus, ma recommandation, c'est entraîne-toi.
Fais des catas, fais des catas, et encore des catas.
Entraîne-toi, même sur simplement,
fais des coding dojo sur Coding Game,
ou trouve des catas, ou fais le calendrier de l'avant du code.
Entraîne-toi.
Mais même sur des choses qui semblent basiques,
parce que traduire l'intention au début,
c'est vraiment pas si simple que ça.
Et donc, ne t'attaque pas à des problèmes algorithmiques
qui perdent compliqués.
Tu peux simplement, par exemple, prendre...
Par exemple, il y a un des catas que je propose dans le module 4,
c'est fait une stack, défini une stack,
une classe stack,
et qui a trois méthodes de pub, push, ou je ne sais plus quoi,
ou count, et tu dois simplement traduire l'intention,
écrire les tests de cette classe.
Tu n'es même pas obligé à la rigueur d'écrire le code réel.
Et d'ailleurs, au début, ce que je recommande,
c'est d'essayer, c'est de traduire les tests,
d'écrire les tests qui te viennent par la tête,
justement, sans écrire du code effectif,
parce que sinon, tu vas être trop tenté de partir dans l'implémentation,
et de plus réfléchir, conception de ton cahier des charges,
conception de tes attentes vis-à-vis de cette classe,
et de la définition de son comportement.
Tout ça, j'en parle de manière assez approfondie
dans le module 4 du cursus artisan développeur,
bien évidemment, si tu as envie d'aller plus loin et qui est curieux,
je t'invite à nous rejoindre dans la maison des compagnons,
sur maison.artisandeveloppeur.fr.
Je te dis à demain.