Bienvenue sur le podcast Artisan Developer, l'émission pour les
programmeurs qui veulent vivre une carrière épanouissante. Prêt à
passer au niveau supérieur ? C'est parti !
Aujourd'hui je réponds à un email de Steven, Steven, merci pour ton message
parce que les questions que tu poses sont vraiment intéressantes et me
permettent de faire ce podcast. Dans cette email tu me parles de ton passé,
tu me dis que tu as fait pas mal de tdds jusqu'à maintenant et que tu te
poses un petit peu des questions parce que tu dis j'ai l'impression de pas avoir
touché l'essence du tdds puisque j'utilise quotidiennement mon
debugger. Alors je te confirme que c'est quand même un signe intéressant, tu as
raison de te poser des questions parce que si tu utilises ton debugger en tdds
c'est qu'il y a effectivement quelque chose d'étrange. Tu me dis aussi qu'en
refacteur notre code il arrive que nous devions retoucher à plusieurs tests
plus de cinq. Je me dis que c'est normal mais mes collègues qui écrivent leurs
tests après me disent qu'il y a trop de tests et que c'est pas normal.
Alors si le fait que tu refactors ton code casse des tests,
tu as vraiment des questions à te poser mais il faut qu'on se mette d'accord sur
les termes. Refactorer le code c'est bien changer l'implémentation interne sans
forcément changer son comportement. Donc là effectivement tu vois quand tu dis ça,
si jamais tu casses des tests en faisant vraiment du refactoring et non pas en
évoluant le fonctionnel, c'est a priori probablement que tes tests et ton code
sont trop couplés. C'est à dire que la manière dont t'as écrit le code dont il
est implémenté est traduit dans les tests. Là tu peux chercher un petit peu du côté
de non plus chercher à tester très unitairement le code. Ce que je veux dire
c'est pas venir chercher à tester de manière profonde le code mais de rester
en surface du code que tu test. Par exemple tu as une classe ou un ensemble de classes qui
exposent un contrat public. Le meilleur moyen d'éviter le couple là c'est vraiment de rester au
niveau des méthodes publiques pour te permettre de rester vraiment sur le comportement. En fait
il faut vraiment que les tests viennent capturer le comportement plus que l'implémentation
concrète. Je ne sais pas si c'est une pisse qui va t'aider, j'espère que ça sera le cas mais
en tout état de cause si le fait de changer du code juste de le refactorer casse des tests
je te confirme que tu as quelque chose à explorer et à trouver pour améliorer les choses. Après
tu me dis je suis tombé dans pas mal de choses concernant le TDD, les styles London, Chicago,
Approach Inside Out, Inside It, les modes classiciste et moquiste. Du coup j'aurais aimé avoir ton
avis sur ces différents styles. En fait mon avis c'est que j'en ai pas. J'ai pas vraiment d'avis
parce que ce genre de nuances me passe un petit peu au-dessus de la tête pour parler directement
je m'en fous un peu en fait. J'ai lu des choses sur ces sujets là et j'ai trouvé intéressant le
modèle qu'ils offraient parce que ça permettait de se dire attire effectivement, ça permet de
mettre des mots sur des pratiques mais de là à choisir là-dedans une combinaison de ces trucs là
par exemple du London Outside It, une classiciste ou du Chicago Inside Out moquiste et en faire les
régions en religion non clairement pas c'est pas mon style et en plus encore une fois c'est pas
comme ça que je réfléchis quand je suis en train de coder, quand je suis en train de tester,
je réfléchis pas en termes de savoir est-ce que je le fais bien, pas bien, je réfléchis à l'intention
que j'essaye de traduire. Qu'est-ce que je veux faire ? Qu'est-ce que j'aimerais que ma classe
soit capable de faire et je le traduis tout simplement en code. Est-ce que tu utilises toujours un style
où il t'arrive de changer ? Bien sûr j'utilise un style lumien et ça renvoie à ton titre est-ce
qu'il existe plusieurs façons de faire du TDD ? Oui clairement il existe peut-être autant de
faire du TDD de développeur parce que chacun va avoir son style parce que chacun va être dans un
contexte différent dans une stack différente avec des outils différents avec des collègues
différents, chaque situation est unique donc le style va vraiment s'adapter à ce qui m'arrive de
changer bien sûr à chaque élément de contexte qui peut varier je m'adapte si j'arrive dans
une équipe qui a déjà une certaine manière de faire je vais faire de mon mieux pour respecter
cette manière de faire et apporter une certaine cohérence parce qu'à un moment donné j'estime
que la cohérence du code prime sur les appétences individuelles ou les manières de faire individuelle
parce que la cohérence est ce qui permet à l'équipe de mieux gérer son peu de code donc
pour moi clairement ça passe devant. Dernière question tu me dis j'ai lu que certaines personnes
trouvent qu'à l'approche moquiste est le faux TDD quand pense-tu ? Il faut découper la réponse là
il y a deux niveaux de réponse il y a intrinsèquement est-ce que je pense que une approche moquiste c'est
personnellement mais c'est très personnel comme à lui je ne suis pas un grand fan des moques donc je
les évite je les évite parce qu'en fait je considère toujours que en faisant un moque tu
découples de la réalité c'est d'ailleurs bien ce que tu cherches avec un moque mais du coup tu te
prives de l'occasion de tester ta chaîne de bout en bout je ne suis pas un grand fan des tests
ultra unitaires d'ailleurs derrière la notion d'unitaire ça vaut le coup de se poser la question
de qu'est ce qui est unitaires est-ce que c'est une classe est-ce que c'est une méthode est-ce que
c'est un ensemble de classes qui ont une certaine cohérence de sens et de fonction mais bref moi je
suis plutôt fan des approches end to end ou un test va venir traverser toutes les couches de bout en
bout je sais que ça va en faire hurler certains et je m'en fous en fait parce que c'est ma manière
de faire moi ça me convient dans mon contexte à moi ça me convient alors j'ai un inconvénient avec
ça puisque comme je tape sur la base de données je vais taper sur des réseaux des trucs comme ça
c'est que les tests vont être lent et qu'à un moment donné je vais avoir une batterie
si le projet se développe beaucoup qui va durer plusieurs minutes devant dépasser le quart d'heure
et là je commence à avoir une stratégie de de réduction de ce temps là je cherche à réduire
ce temps là et certains pourraient agir en disant oui mais si tout de suite tu étais parti sur une
approche complètement découblée tu aurais passé problème là c'est vrai c'est vrai et je répondrais
que tout est une question de compromis moi dans le type de projet que je fais avec la durée de
vie de projet que je fais ça me convient ça me convient très bien en fait et j'en arrive du
coup au deuxième niveau de lecture de ta question il y en a qui disent que ceci est du faute et dd ou
du vrai dd tu raccombris que je suis pas un grand fan de ces de ces questions où tu te poses un peu
en gourou avec une espèce de dogme on disant voilà la voie à suivre la lumière est là à
suivre là je suis pas un grand fan de ça ça veut pas dire que ce soit mal et ça renvoie à une
autre question qui est qu'est ce que tu attends en fait qu'est ce que tu attends des autres parce
que si tu attends un gourou ben tu trouveras un gourou si tu attends quelqu'un qui t'amène une
manière de réfléchir il t'apprend à réfléchir par toi même bah c'est ce que tu trouveras et
c'est plutôt ce que j'ai à proposer d'ailleurs tu remarqueras dans le cursus artisan développeur
on m'a parfois fait le reproche de dire ah oui mais tu me donnes pas une feuille de route détaillée de
comment implémenter le truc exactement dans mon cas et je te répondrai en effet ce que j'amène
avec le cursus artisan développeur c'est c'est plus un framework qu'une implementation c'est plus
une manière de réfléchir une manière de structurer les choses une manière de de voir les choses de
comprendre les choses avec un peu de recul et d'expérience parce que derrière tout ça se cache
aussi beaucoup d'enjeux humains et je pense que les maîtres de côté et simplement dire voilà
comment il faut faire avec un guide détaillé étape par étape je crois pas en cette recette mais
il sait pas parce que j'y crois pas que d'autres personnes n'ont pas le droit de le faire ils font
ce qu'ils veulent tant qu'ils trouvent des gens à qui s'appeler qui ont envie de suivre ça moi je suis
ok avec ça je suis pour la liberté chacun tu vois donc si tu as envie de suivre un guru sur un
guru et si ça te permet d'avancer c'est très bien c'est que ça te fait ton bout de chemin peut-être
un jour tu aurais envie de suivre un autre chemin et si tu as envie de ne pas réfléchir par toi
même je t'invite à continuer à écouter ce podcast et peut-être à t'intéresser aussi justement
au cursus artisan développeur qui réouvre ses portes une à deux fois par an donc le temps que
tu écoutes ce podcast probablement qu'il sera bientôt temps de remettre en place de réouvrir
le cursus je pense le réouvrir cette année en vers novembre là on est en 2020 au moment où j'enregist
cet épisode donc en novembre je pense réouvrir le cursus donc si ça t'intéresse pense bien sûr à
t'inscrire sur la communauté artisandeveloppeur.fr ça te permettra d'être prévenu du lancement
vraiment le tdd et c'est ça que je dirais en conclusion c'est quelque chose de simple c'est
à la fois génial et extrêmement simple et c'est ça un petit peu le génie de kainbek quand
il sort ce truc là le tdd c'est quoi c'est un cycle c'est rouge verbeur c'est j'ai créé un tasquée
chou je fais passer le test le plus rapidement possible je refactorise mon code tu vois voilà
tu connais le tdd en 30 secondes je te l'ai expliqué et pourtant il va falloir des années de pratique
pour réellement le maîtriser donc fais ton chemin et c'est ça que je te dirais en conclusion
faites mon propre chemin suite à route fais confiance à tes intuitions à ce que tu ressens
le code te parle le code te dit des choses si tu si tu es prêt à l'écouter il te dit quand les choses
vont bien quand c'est fluide irrapé des faciles c'est que tu es sur la bonne voie si au
contraire c'est lourd pénible que tu commences à faire des trucs compliqués que tu commences à écrire
du code du code du code et que tu te retrouves à galérer pour faire des trucs qui ne marchent pas
bien qui sont pas fiable dans le temps c'est que tu es a priori peut-être pas sur la bonne voie
quelle est la bonne voie ben c'est à toi de le découvrir c'est à toi de chercher mon gars voilà
j'espère que cet épisode t'aura aidé cher auditeur si toi aussi tu as des questions n'hésite pas à
les envoyer benoît un rebase artisan développeur comme s'y venent et soit je te répondrais en privé
si jamais j'ai pas que ça j'estime que c'est pas une réponse propice pour faire un podcast soit
comme là là ben je te ferai une réponse par podcast je te remercie je te dis à bientôt