Comprendre les tests unitaires pour enfin en faire

Table des matières

Comprendre les tests unitaires pour enfin en faire

Une expression dont vous avez déjà entendu parler, j’imagine ? Moi j’en ai entendu parler entre la fin de mes études et le début de mon premier contrat professionnel en tant que développeur web.

Les fameux tests unitaires.

On se renseigne, on regarde de quoi il s’agit, on essaie et puis au final on abandonne pour diverses raisons. À l’époque pour ma part je trouvais que c’était une perte de temps.

C’est un peu l’excuse que j’avais trouvée et tu es peut-être dans ce cas là.

Laisse-moi te raconter mon histoire avec les tests unitaires et t’expliquer comment franchir le cap !

Source : https://www.commitstrip.com/fr/2013/10/11/mieux-et-moins-cher-que-les-tests-unitaires/ 🔗

J’ai un aveu à te faire

Ce que je compte t’avouer risque peut-être de te choquer. Pour rappel à l’heure où j’écris ses lignes j’ai commencé le code il y a un peu plus de 13 ans et cela fait 10 ans il y a quelques mois que je suis dans le monde professionnel en tant que développeur web.

Si je te dis que cela fait que quelques mois que je réalise réellement des tests unitaires, tu me crois ? Oui tu lis bien pendant plus de 9 ans dans le monde professionnel, je n’ai JAMAIS fait de tests unitaires dans mes projets.

La raison principale étant la plupart du temps la plus facile : le temps. Mais en réalité, c’était bien plus profond que cela.

L’un des vrais facteurs c’était comment le faire comprendre non seulement à ma direction de l’époque qui aimait bien que l’on estime nos projets un peu à la louche et souvent au rabais pour que le projet passe et que le client accepte de payer pour réaliser des tests unitaires.

Des années à comprendre que j’empruntais une mauvaise route

Sauf que travailler sur ces points n’était pas la bonne stratégie, mais surtout cela n’était pas valable. Il faut partir du principe que l’on a tout le temps de faire des tests. Comme on a tout le temps de réfléchir à concevoir un projet et à le coder.

Cela fait partie de notre métier et peu importe la personne que vous avez en face, elle doit comprendre que c’est comme ça et pas autrement, point !

Votre direction ou votre client ne doit pas vous dire comment vous devez travailler et donc si vous devez en faire ou non.

Allez-vous par exemple dire à un chirurgien ce qu’il doit faire ou ce que vous ne voulez pas qu’il fasse ? Je pense que si vous le tentez, vous pouvez être sûr que le chirurgien ne va pas vous opérer.

Même si l’image est un peu décalée et que ce ne sont pas les mêmes enjeux, vous avez compris le principe.

On ne doit pas vous dire comment faire et vous êtes en droit de refuser de travailler avec quelqu’un qui veut faire l’impasse sur des parties que vous jugez essentielles.

La stratégie de communication (et commerciale que vous devez avoir) ce pas de dire que vous vendez juste du code et des talents de programmeur, mais de vendre un tout qui représente ce que vous êtes à savoir votre capacité à raisonner, à gérer un projet et à produire un travail de qualité.

Le code, les tests unitaires ou le choix technologique sont donc anecdotiques dans la conversation que vous pouvez avoir avec votre direction ou votre client.

Ne l’oubliez pas !

C’est quoi les tests unitaires ?

Maintenant que nous avons clarifié le manque de temps, on va maintenant parler de tests unitaires. Mais c’est quoi au juste les tests unitaires ?

La définition de Wikipédia 🔗.) dit la chose suivante : «  En programmation informatique, le test unitaire (ou « T.U. », ou « U.T. » en anglais) ou test de composants est une procédure permettant de vérifier le bon fonctionnement d’une partie précise d’un logiciel ou d’une portion d’un programme (appelée « unité » ou « module »). ».

En clair, c’est écrire du code pour tester le fonctionnement de notre code. On a donc la légitimité de se dire que si les tests c’est du code, faut-il tester les tests ?

Non bien sûr, car il y a une règle à respecter quand on réalise des tests unitaires : il ne doit y avoir AUCUNE condition dans l’écriture de vos tests. En clair, pas de condition « si », de boucle en tout genre comme les « for » ou les « whiles ».

Pour rappel, ce qui fait l’intérêt des langages de programmation c’est de pouvoir réaliser des opérations en respectant des règles que vous avez établies sous forme de conditions.

Mais cet intérêt va aussi provoquer ce qu’on appelle des bugs provenant soit d’une défaillance en niveau du code que vous avez écrit soit un comportement non voulu dans votre application comme un cas non géré par exemple.

Les tests unitaires vont donc permettre de vérifier que le code que vous avez écrit fonctionne et gère les cas évoqués et demander par votre client. Voyez cela comme une sorte convention entre vous et votre client.

Pour vous, cela vous offre une sécurité sur le long terme.

En effet, en testant chacune des parties de votre application, son évolution et sa maintenabilité seront plus faciles et vous ne serez plus en stress de savoir si vous avez cassé quelques choses en modifiant une partie de votre application.

Le lancement de vos tests vous le dira directement si quelque chose cloche.

Pour votre client, cela permet d’avoir une plus grande certitude que ce que vous avez codé est conforme à ce qu’il vous a demandé.

Même s’il ne comprend rien à la programmation, il est capable de comprendre d’un point de vue métier le résultat qu’il ressort de vos tests.

Pas facile de s’y mettre

Comme vous voyez comprendre en quoi consistent les tests unitaires, ce n’est pas difficile : on teste le code de notre application pour vérifier que tout fonctionne bien.

Oui, mais comment en faire ?

C’est ce cap qui est difficile à franchir parce qu’on est un peu livré à nous même et qu’on ne sait pas par quoi commencer.

Il faut savoir que l’apprentissage d’écriture des tests unitaires n’est pas une chose très répandue.

Là où à l’école ou en formation, on vous apprend à réfléchir et à faire du code, peu d’entre elles aborde dans leur cursus l’écriture et l’importance des tests unitaires dans votre carrière de développeur.

Au meilleur des cas, on vous l’évoque et on survole cette partie au même point que la sécurité de votre code.

Les 2 principaux freins aux tests unitaires

Elles peuvent varier d’une personne à une autre, mais voici les 2 plus communes que l’on retrouve le plus souvent.

«  Je ne sais pas ce que je dois tester exactement sur ma portion de code »

Si vous n’avez jamais fait de test unitaire, vous devrez très certainement tester manuellement votre application. Vous mettez des valeurs et vous vérifiez que celle-ci produit ce que vous demandez.

C’est ce que vous devez faire avec vos tests unitaires. Vous allez tester votre portion de code et surtout ce qu’elle ne doit pas faire.

Cela va constituer une bonne base pour l’écriture de votre test. Si vous avez plusieurs cas à tester, vous allez tout simplement écrire des tests pour chacun de ses cas.

«  Je découvre les tests unitaires en fin de projet » :

C’est le plus compliqué à gérer et celui qui peut vous faire renoncer à commencer à en faire. Vous êtes sur un projet déjà bien lancé et vous voulez mettre en place des tests unitaires.

Le problème c’est que vous ne voyez pas par où commencer, car il y a du code partout et énormément à tester.

Vous avez tout simplement l’impression qu’il vous faudra autant de temps à les écrire plutôt que d’avoir codé l’application.

Alors que faire ?

Il n’y a pas de recette miracle, mais vous pouvez mettre en place une stratégie pour ce cas de figure.

Je vous conseille tout d’abord d’écrire des tests sur les parties de codes qui vous restent à écrire pour finaliser votre projet.

Ce sera plus simple pour vous, mais également plus interactif. Pour tout le reste du code que vous avez écrit, il faut le faire au fur et à mesure.

Le meilleur moment selon moi, c’est de le faire quand vous faites évoluer vos parties codes lors d’amélioration de l’application ou correction de bug.

Ce sera long à tout mettre en place, mais au moins vous allez plus facilement mettre des tests dans votre application ce qui est toujours mieux que de ne pas en avoir.

La stratégie à adopter pour que les tests unitaires deviennent une habitude

Tout comme le code, vous devez écrire vos tests de manière stratégique.

Le premier point c’est d’abord de choisir le framework que vous allez utiliser pour réaliser des tests dans votre langage préféré.

Étudiez-le et exercez-vous avec sur de petites portions de codes peu complexes pour vous faire la main. Il n’y a rien de plus déroutant que de se faire la main sur quelque chose de totalement nouveau lors d’un lancement de projet.

Cela vous enlèvera un stress.

L’idéal est de pouvoir la définir et l’appliquer au début d’un projet avant même la première ligne de code.

Car vos tests dépendront du langage de programmation, le framework, l’organisation de votre code ainsi que votre niveau en programmation de manière générale.

Il y a 2 grandes écoles en matière de tests unitaires : ceux qui pensent qu’ils doivent couvrir 80% de votre application et ceux qui pensent que cela doit être 100%.

Je n’adhère personnellement à aucune d’entre elles.

Je pars du principe que ce qui est utile d’être testé doit être testé tout simplement. Inutile de tester du code dépourvu de logique.

Je vous donne un exemple.

Imaginons que vous créez une API qui est décomposée avec des contrôleurs et des services pour simplifier.

Vous avez fait en sorte que toute la logique de votre application soit contenue dans votre service.

Votre contrôleur va juste desservir le traitement de votre service. Dans ce cas de figure, il est inutile de tester le contrôleur avec des tests unitaires, car il est complètement dépourvu de logique.

Vous allez uniquement les réaliser sur vos services.

Si vous voulez tout de même tester le résultat que renvoie votre contrôleur, il sera plus judicieux de passer par des tests End-to-End.

Ce que vous devez aussi prendre en compte ce sont les cas à tester. Vous ne devez pas vous focaliser que sur le résultat que votre code doit produire, mais aussi les résultats qu’elles ne doivent pas produire. C’est très important de couvrir les tests négatifs que positifs.

Epilogue

Dernier point à prendre en compte dans votre stratégie. Tout comme le code que vous produisez, celui-ci ne sera pas parfait dès le début.

Rappelez-vous les premières lignes de code que vous produisiez et ce que vous faites maintenant.

Vous avez évolué. Et bien avec les tests c’est la même chose. Ne soyez pas perfectible, mais réalisez quelque chose qui fonctionne en termes de test.

N’oubliez pas qu’il vaut mieux un petit quelque chose plutôt que rien du tout.