Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Michael Azerat, Michael bonjour.
Bonjour Vénorin.
Et je préviens tout de suite les auditeurs aujourd'hui on fait une expérience avec Michael.
Donc si tu écoutes cet épisode c'est que l'expérience aura été concluante.
On va jouer au jeu de, c'est Michael qui anime donc je lui passe le relais d'animation.
Il va me faire parler.
Et Michael, souviens-toi, l'objectif c'est moins de 10 minutes.
Exactement.
À vous les studios.
Ça marche.
Alors Vénorin je pensais à un sujet très important justement en matière de couverture
de tests et vraiment de d'excellence technique.
Est-ce que tu as lu toi dans tes précédentes missions ou même actuelles etc.
Un manager qui vient et qui vous dit écoutez on aimerait avoir une couverture de tests à 100%
ou en tout cas qui tend vers 100%.
Et là on lui répond pourquoi.
Il te dit bah pour être sûr que le code n'est plus de régression.
Comment est-ce que tu...
Comment est-ce que tu interprètes en fait cette demande ?
Qu'est-ce que tu en fais ?
Comment tu la juges ?
Qu'est-ce que tu en penses ?
Est-ce que ça sert ?
Est-ce que ça sert pas ?
Comment vous juger ça vous votre équipe en fait ?
Donc le manager on veut 100% du couverture.
Qu'est-ce que tu lui répondes ?
Alors déjà si un manager ou un client ou quelqu'un à quelque part qui...
Qui je rende des comptes d'une manière ou d'une autre.
Venez avec ce genre d'exigence.
D'abord je serais ravi parce que ça serait le signe d'une grande maturité.
D'accord.
Ensuite je l'ai déjà vu dans certaines entreprises.
Je l'ai déjà vu faire dans certaines entreprises notamment CAC 40 dont j'autérais
le nom et là effectivement du retour même des collaborateurs c'était un peu ridicule
parce qu'à un moment donné ils créaient des tests.
Là au moins c'était très clair il y avait zéro assertion.
D'accord.
Au moins on ne pouvait même pas essayer de faire semblant mais au moins il y avait de
la couverture.
D'accord.
Moi j'ai un retour d'expérience où dans une de mes anciennes boîtes pour sensibiliser
les gens j'avais essayé même de dire on va en faire une métrique et on va même mettre
des primes sur le fait que la métrique augmente.
D'accord.
Et je m'attendais moi à ce que la métrique augmente parce qu'en fait si on...
On veut que la couverture augmente c'est assez facile de couvrir le code.
Bah même pas en fait j'avais été un peu déçu de voir qu'ils n'avaient même pas
essayé de gruger.
C'est vrai.
Mais moi je peux te parler de nous ça reste une métrique je ne vais pas dire centrale
c'est plus une métrique de check de satisfaction.
Aujourd'hui il y a des qualités checks sur des qualités gates sur ça c'est-à-dire
que si jamais tu fais baisser la couverture de code la PR est rejetée.
Maintenant je reste et je crois que je reste très lucide ça veut simplement dire que
le code a été exercé.
Ça me prémunit d'un crash quelque part mais ça veut pas dire que le code a été testé
soyons clairs.
Alors là on va se concentrer juste je comprends très bien ce que je dis c'est intéressant.
Le manager lui ce qu'il veut c'est un pourcentage.
Lui il ne va pas aller voir plus loin il veut que ça soit vert un petit point vert.
Alors pourquoi je dis ça parce que ça m'est déjà arrivé moi dans une des...
Dans une 3 missions.
Ou le manager.
Ah le manager arrivé c'était un des objectifs.
Ah c'était l'objectif complet.
Ah bah tu avais des bons clients toi quand même.
Les managers on dit on arrête de bosser sur les US et compagnie pendant 2 semaines
faut que la visée couverture de test.
C'était ça le mot d'ordre c'était une réalité donc c'est pas j'ai pas menté
c'est une vérité.
La question c'est je te dis maintenant c'est un pourcentage.
Est-ce que tu peux partir du principe que si tu as 89% de code coverage c'est que ton
code est bien.
Ça dépend comment ça a été fait.
Si ça a été fait en TDD j'ai envie de te dire ça m'inquiète que ce soit que 89.
Ouais.
Parce que ça veut dire que tu n'as pas vraiment été rigoureux.
Maintenant si tu as couvert juste pour couvert c'est-à-dire que tu as fait du vert sur du
vert ça ne vaut littéralement rien en fait.
Alors quel est le risque justement si on est amené à gruger en fait parce que c'est
très facile à gruger j'ai une anecdote en un mot quelqu'un avait créé un fichier
de 40.000.000 avec énormément de code à l'intérieur dans une méthode qui faisait

quand même une mesure intéressante.
On ne peut pas se fier qu'à ça.
Mais après tu as plusieurs mesures de la couverture citée en nombre de lignes de code.
Très clairement ça ne veut pas dire grand chose parce que finalement les cas au limite
et les maires en général elles sont dans les 5% de gestion des cas d'erreur qui ne
sont pas couverts.
Par contre je trouve qu'il y a dans la mesure en code coverage par branche une mesure qui
est assez intéressante parce qu'elle te permet quand même de savoir si tu passes un peu
partout ou pas dans ton code.
Est-ce que tu penses que c'est possible d'écrire les tests après avoir codé d'essayer d'avoir
un bon code code coverage ou est-ce qu'on peut avoir un bon code code coverage en écrivant
des tests après avoir codé.
Donc on a un algorithme et puis on nous demande maintenant on va faire un test unitaire.
Oui à une grand-dition moi quand je fais ça c'est à dire que je me rends compte que
soit je reprends du code legacy ou quoi.
En fait je mets en commentaire le code.
Je le mets en commentaire et je redémarre une démarche de TDD et si j'arrive à avoir
une barre rouge qui me prouve que mon test sert à quelque chose à ce moment là j'avance
et je décommente petit à petit au fur et à mesure de ce que j'avance.
Et là moi j'ai le sentiment d'avoir quelque chose qui tient la route.
Je sais pas ce que t'en penses.
Complètement.
C'est une bonne approche que je pratiquais pendant le moment.
Franchement j'aime beaucoup cette approche.
C'est en fait une approche rewrite par copie en fait.
C'est un peu du reverse engineering mais pour réécrire en fait.
Donc c'est assez intéressant.
Maintenant le problème du code coverage c'est que on peut mettre tout le monde joyeux
rapidement avec du verre.
On allait dans les réunions et tout le monde était content etc.
Le problème c'est qu'après il faut les maintenir ces tests mais ils sont illisibles
et des fois ils sont trop complets parce qu'il fallait couvrir le maximum de code et surtout
ils n'ont aucun sens.
Donc ça va laisser en fait du code des règles de gestion très fines qui sont dans le code
qui sont complètement laissées non testées mais traversées.
Donc le prochain développeur qui arrive il va voir un test il va voir que ça traverse
dans le rapport il va marquer cette classe et tester pourquoi je vais la tester.
Alors maintenant la question que je te pose c'est est ce que tu as entendu parler du mutation
testing ?
Ah bah oui j'adore.
J'adore ce truc là moi j'ai les yeux qui sont mis à briller j'ai rêvé de ça.
C'est bon là.
Ah ouais non franchement aujourd'hui pour moi le mutation testing j'ai envie de dire
dans notre domaine pour moi dans le craftmanship c'est ce qu'il y a à la frontière tu sais
la frontière entre le connu et l'inconnu entre pour moi travailler sur mutation testing
aujourd'hui avec cet outil là c'est vraiment être là pour le coup au-delà de l'état
de l'art.
C'est-à-dire en avance c'est d'aller explorer au-delà de l'état de l'art.
Et de se résumer du coup en quelques phrases pour les auditeurs justement qu'est-ce que
c'est mutation testing ? Qu'est-ce que ça apporte par rapport au code coverage ? Quel
rapport avec le code coverage ?
Le principe du mutation testing c'est de venir zombifier ton code c'est-à-dire de venir
l'éclater devenir l'altérer.
Un petit exemple ? Un petit exemple tout bête ?
Bah un truc tout bête tu as une condition if condition bah tu mets un if not condition.
D'accord très bien.
Et tu vois si les tests gueulent ou pas c'est-à-dire est-ce que ton zombie c'est fait qu'il est
par les tests ? Exactement.
Si ton zombie c'est fait qu'il est par les tests à un point si ton zombie c'est pas
fait qu'il est par les tests à zéro point et tu perds un point et après tu prends le
nombre de mutations et tu regardes combien quel pourcentage a été tué.
Je pense que ce truc là ferait pas lire beaucoup de développeurs et très franchement je…
En fait maintenant quand je code en TDD je code avec ça en tête mais en sachant que
je suis jugé par la couverture.
Donc il y a des fois je me dis oh ça ça ne passerait pas à la mutation mais je m'en
fous parce que je regarde que la couverture.
Exactement.
Et je sais que je me ferai… je pense à Vunay qu'on tomberait autour des 40 à 50%
de mutations.
Ouais.
Je pense qu'on aurait une sacrée surprise.
Pas… pas… pas catastrophique tu vois.
Je pense qu'on tomberait bien avec 30-40.
Et toi la première fois que tu as utilisé…
Après je te finis ça.
Le problème que j'ai eu avec la mutation c'est que j'ai essayé sur un projet qui
est sur du Rails.
La jambe sur Ruby marche bien mais le passage à Rails est assez… en tout cas n'a pas
été aussi fluide que tout ce que j'ai pu tester sur et j'ai vite abandonné.
D'accord.
Mais c'est un truc que je pense que je… c'est un sujet vraiment qui m'intéresse.
Mais je suis curieux toi.
Toi tu l'as… je crois que tu l'as expérimenté.
Ça a commencé…
Ah ouais c'est la place dans le grand compte.
Comment tu es ?
Ça a donné quoi le jour où t'es passé de coverage à mutation ?
L'écart de statistique t'es passé de combien à combien ?
Alors… alors sincèrement en fait j'ai pas eu d'écart monumental.
Pourquoi ? Parce que quand tu fais du TDD strictement forcément…
Oui t'as un peu d'écart.
Si tu strictes…
Ouais tout à fait.
Voilà.
Donc c'est pour ça que justement les deux mâches très…
Le mutation testing en fait c'est une pratique qui va permettre de vérifier que ton TDD
est bien fait.
En gros c'est ça.
C'est un peu un flick, c'est un flick.
C'est le flick du flick.
TDD c'est le flick c'est un peu le principe de flicker ton code.
Et mutation testing va fliquer ta pratique qui flick ton code.
Voilà c'est un peu ça.
Est-ce que tu le fais dans les règles de là ?
Dans une précision extrême.
C'est vraiment ça.
Donc ça veut dire si à un moment donné dans mon code j'ai inférieur ou égal et en
fait il fallait inférieur et j'ai mis inférieur ou égal, ce qui est beaucoup moins restrictif.
Le code va me dire bah désolé pourquoi t'as mis inférieur ou égal ?
Ça ne servait à rien de mettre égal.
C'est un cas qui n'arrive jamais.

Et donc à partir de là ton code va s'affiner et il va te montrer exactement…
Il va être le reflet de la réalité.

Et donc fatalement ça va t'apporter une couverture de code, un pourcentage qui est complètement
fiable parce qu'il va vraiment te dire que toutes les lettres qui sont écrites dans
ton code ont toute une justification, toutes, même les opérateurs, toutes.
Et donc ça c'est très bon.
Donc moi j'ai mis pendant un an, ma dernière mission en freelance que j'avais faite dans
un grand groupe, j'ai imposé le mutation testing avec un développeur aussi qui était
vraiment à fond.
D'ailleurs je lui ai confié, c'est lui qui l'a mis en place sur le projet.
Donc on avait un rapport généré etc.
C'est lui qui avait configuré tout ça etc.
Vraiment très sympathique.
Et ça permet de consolider notre confiance en auteste déjà et d'apporter une sorte
de précision, de sorte de bonus à montrer au manager en disant écoutez on a 40 000
lignes de code dans l'application, bah ouais mais on ne pouvait pas avoir 30 000 parce qu'on
t'avait pas besoin de plus, t'avais pas besoin de moins.
Donc vraiment on a vraiment le produit perfect en fait.
C'est ce que vous avez demandé, on vous l'amène.
Donc les couves évidemment ils sont réduits si on les joue fréquemment.
Et donc voilà, mutation testing c'est génial parce qu'il permet de rendre fier de son code
en se disant j'ai quillé tous les mutants.
Toutes les finesses de mutation testing elles sont parties.
Le truc que j'ai vu aussi c'est que c'est long parce que du coup à chaque fois que
tu fais mutation faut relancer toute la batterie.
Ça sent le soir ou tous les deux jours environ.
Voilà on est d'accord et moi j'avais ce souci là.
Et plus tu vas vouloir une couverture exhaustive et plus c'est long plus tu vas devoir créer
de mutants.
Exactement non c'est un truc qui tourne la nuit en fait.
Il faut le faire tourner la nuit c'est du jour de deux heures puis ça tourne la nuit
et on demande à le rapport.
Mais encore une fois si tu as la bonne pratique TDD normalement tu n'as pas de surprise derrière.
Par contre si tu n'as pas de pratique TDD là c'est plus les mutants là c'est plus
des zombies c'est des ulpes que tu auras dans la piste.
Ah oui oui on est d'accord que c'est une pratique inattes de sens que si tu es déjà
à 95% de couverture.
Si tu as un cher auditeur si tu écoutes ce podcast et que tu n'as pas encore 95% de couverture
commence par t'occuper de ça parce que les mutants vont te défoncer.
Exactement ça va être frustrant dès le début.
Il y avait une super vidéo sur internet justement qui en parlait avec des exemples qui fait
jouer le public.
Le mec fait jouer le public en montrant un code de 4 lignes et en disant pour vous comment
test il faut pour tester ce code là.
Tout le monde s'est planté tout le monde s'est vautré.
Et il te dit c'est pour ça que tu as aidé là et justement cette pratique qui permet
de justifier.
C'est pour ça que je ne peux pas tester après coup.
Quelqu'un qui me dirait aujourd'hui se peut tester après coup après avoir eu le code
c'est un menteur.
Un vraiment tœur.
Alors il pourra tester sur des cas faciles dès qu'il y a un peu de hives, de hells,
de trucs, de wilde, de fort et il est mort.
Et donc ça c'est un cas vraiment sympa mutation testing c'est pour être fier de son code
et surtout pour que la machine nous prouve qu'on est vraiment dans la bonne direction.
Ça c'est vraiment génial.
Ça se complémentent en fait aux autres pratiques.
Moi je suis dis pitheste en fait.
Pitheste en Java qui est en mon avis la librairie la plus avancée sur le sujet.
Pitheste en Java, vous pouvez voir sur le site pitheste p-i-t-e-s-t.
Et c'est une des librairies les plus avancées en mutation testing qui fonctionne très
bien dans mon Java.
Ah bah écoute, Mika, je te propose que ce soit le mot de la fin.
Très bien.
Et donc voilà, merci pour ton ressenti sur les couvertures de tests.
C'est un sujet que les managers adorent aujourd'hui parce que pour eux c'est avoir du vert, c'est
avoir une confiance énorme en leur développeur.
Et voilà, faut s'en méfier aussi.
Et c'est pour ça qu'il y a plein de pratiques qui sont là pour essayer de protéger les
développeurs et surtout de les amener à prendre encore plus soin de leur code.
Ça c'est génial.
Être plus fier de ce qu'ils font encore et être passionné.

Écoute, super.
Si les auditeurs ont envie d'en savoir plus sur ce que tu fais, ils vont ouf.
Alors ils vont sur Willcomecompany.com.
C'est un site internet que j'ai monté qui me présente ma société, Willcome.
Ça s'écrit W-E-A-L-C-O-M-E, company en anglais, et en gros je propose des réalisations
de projets from scratch au forfait.
Donc vraiment de A-A-Z, une application logiciale, etc.
Fait dans les pratiques et règles de l'art du software craftmanship.
TDD, BDD, DDD, enfin tout aussi prête.
Tout est là dedans.
Pour livrer un produit sans bug et je m'assure et je garantis zéro bug à la sortie.
Il livrait dans les temps.
Donc vous pouvez aller voir et sinon il y a LinkedIn pour, je poste assez souvent, Michael
Azera vous avez là dessus et à mon LinkedIn vous pouvez m'ajouter aucun problème.
Écoute, super, Michael.
Quant à toi cher auditeur, j'ai un appel à l'action un peu particulier aujourd'hui.
Ça fait très longtemps que je me pose la question.
Est-ce qu'il y aurait de la place pour un service qui te fasse ça, mais de manière
très simple parce qu'en fait le mutation testing, tu as plein de problèmes.
C'est long comme on vient de le voir puisque plus tu as de mutants et plus il faut faire
tourner tes tests.
C'est pas si simple que ça à mettre en place dans un projet.
Il faut configurer plein de trucs et c'est un peu chiant à faire.
Et du coup, je suis curieux que tu me dise.
En vraiment un commentaire, en même un email sur benoirobazartisandeveloper.fr, est-ce
que tu penses que tu serais intéressé pour un service qui te simplifie ça super facilement
pour cotier tes premières métriques de mutation testing ?
Je suis curieux tant autour.
Et sinon, je t'invite évidemment si tu n'as pas encore rejoint la communauté des développeurs
passionnés à venir sur artisandeveloper.fr.
Je te dis à demain.