- Ah tiens, salut. Tu as vu le rapport sur la typologie des tests dans nos projets ? - Ah oui… tu sais moi les rapports… - C'est de la foutaise ce rapport. - Oh? - Pour le projet XXL, le rapport dit qu'on fait 250 fois plus de tests d'intégration que de tests unitaires. - Ah bon. - Et pour cause : on n'en fait pas des tests unitaires. Et donc la figure sur le rapport se présente comme une pyramide inversée. Et Denis nous a fait remarquer qu'elle n'allait pas manquer de se casser la g… et qu'il fallait y faire quelque chose. - C'est qui Denis? - Le nouveau manager en charge de la coordination du projet XXL. - OK. - Foutaises. C'est juste une théorie la pyramide des tests de toutes façons. - Plus une observation qu'une théorie, si tu veux mon avis… - Sur le projet XXL, on a besoin de tester rapidement que ça marche ! C'est sûr on pourrait s'amuser à écrire des tests unitaires pendant des semaines, et ça prouverait quoi ? - Dis-donc ça a l'air de te contrarier cette histoire de pyramide… - Je vois pas l'intérêt, franchement. - Mais si. C'est une analogie. Ça permet de te rappeler que si tu veux construire un système stable, tu as intérêt à valider les parties qui composent l'application avant de valider l'ensemble. - Mais non : en validant l'application, je valide aussi les composants. - Bon. Alors suppose qu'on construise une pyramide en Lego. Justement, on a une boite de Lego ici, qu'on utilise pour faire des lego scrums. - Ah bon ? - Oui. Alors vas-y. Je te passe les briques, et toi tu construis la pyramide. Ne la fais pas trop grande, on n'a pas cent mille Legos non plus. - OK. Passe moi des briques. - Tiens. - Ok. Voilà une base de 8 sur 8. Je ne vois pas ton point, là. - Tiens. - Eh, passe moi plutôt des briques de 4 par 2, pas des plaques. - OK. - Deuxième étage. Tu la veux d'une seule couleur au fait ta pyramide ? - Ah bah clairement. On veut une pyramide, pas une mosaïque. - Alors pourquoi tu me passes des briques de couleurs différentes... - Ah, OK. Voilà. Tiens. - Eh, non ça c'est pas une brique, c'est un chapeau de figurine. Concentre toi un peu. - Oups. Sorry. - Bon. - Tiens. - Une bille ? Qu'est-ce que tu veux que j'accroche une bille sur la pyramide ? - Ah pardon.. -… - Ok. Voilà, pyramide finie. - Parfait ! - Donc c'est quoi ton point ? - Je t'ai regardé construire la pyramide.. - Et ? - Eh bien j'ai observé que chaque pièce que je te passe, tu la vérifies avant de la poser sur la pyramide. - Quoi ? - Tu prends la pièce, tu la regardes, et si elle ne te convient pas, tu la rejettes. Ou si elle semble convenir, tu regardes où tu pourrais la poser sur la pyramide, et seulement après tu la poses. - OK. Si tu le dis. - Tu ne t'en rends pas compte tellement c'est rapide, de l'ordre du réflexe. Tu vérifies d'abord la pièce avant de la poser. Pourquoi tu procèdes de cette façon ? - Pour éviter d'avoir à démonter la pyramide après coup, tiens ! - Voilà. C'est pareil avec le soft. La pyramide des tests dit que les différentes sortes de tests répondent à différentes questions, et qu'il vaut mieux se poser certaines questions avant d'autres :
- C'est là que ton analogie ne marche pas : pourquoi perdre du temps à tester unitairement un programme si l'utilisateur peut te dire en un test de recette que son besoin n'est pas satisfait ? - Parce que son test de recette est très loin de couvrir tous les chemins d'exécutions possibles. Lorsque tu passes à un utilisateur un programme non testé unitairement c'est comme si tu lui disais :
Je te laisse le soin de vérifier que ce programme répond à ton besoin. Il ne contient a priori pas de bugs. Ou du moins il ne contient pas de bugs que tu ne pourrais pas détecter lors de ta vérification.
Or tu sais bien que c'est faux. Demain je change une ligne dans le code de votre projet, et tout le monde n'y verra que du feu. Les tests de recette passeront. L'application ira en production. - Ce n'est pas sûr que ça produirait un bug, du coup… - Alors c'est comme si tu lui disais : Je te laisse le soin de vérifier que ce programme répond à ton besoin. Il ne contient a priori pas de bugs. Ou du moins il ne contient pas de bugs que tu ne pourrais pas détecter lors de ta vérification. S'il en contenait que tu n'as pas détecté, ce serait probablement quelque chose de non-critique. On verra bien.
- Tu pousses l'argument un peu loin quand même ! - Alors dis moi, c'était quoi, la dernière anomalie en recette que vous avez reçue ? - Hmm, laisse moi regarder… Voilà:
ticket 4807: j'appuie sur le bouton Valider et rien ne se passe. Merci de revoir.
- Bon c'est un mauvais exemple. - C'est un excellent exemple. Pourquoi rien ne se passe ? - Le code du bouton lance bien la méthode de mise à jour, mais celle-ci plante. - Pour quelle raison la méthode de mise à jour plante ? - Le service appelé ne répond pas. - Pourquoi le service appelé ne répond-il pas ? - Il appelle une fonction de formattage, mais celle-ci renvoie une erreur NPE. - Pour quelle raison ? - Un problème de logique dans un if else… On peut remonter assez loin comme ça. Où est-ce que tu veux en venir ? - Est-ce que c'est l'utilisateur qui a découvert tout ça ? - Non malheureusement, tu penses. - Et ça vous a pris combien de temps ? - Hmm, ça nous a bien pris 4 heures, vu que le debuggeur ne marchait pas sur la configuration de Jérémie. - Et si vous aviez posé un test unitaire sur cette fonction de formattage ? - Je suis d'accord, en fait. - Alors tu es d'accord avec la pyramide des tests.
Pour en savoir plus: Sortie de la carte de référence OCTO sur les tests d'applications Front End
Lightning Talk Meetdup SWC : La Pyramide des Tests
Culture Code: notre ouvrage de référence sur l'Artisanat Logiciel