Les tests unitaires : Une lueur d'espoir

En septembre 2003, je me suis rendu dans la sympathique ville d'Arhus au Danemark pour donner une conférence à la célèbre conférence JAOO. 

À l'époque, JAOO était une conférence bien établie sur le développement de logiciels, avec des intervenants de renom tels que Martin Fowler, Kent Beck, Linda Rising et Erich Gamma. Et moi. 

Lorsque je suis arrivé sur les lieux, un centre de conférence situé en bordure du centre-ville, l'une des organisatrices m'a proposé de me faire une visite guidée du bâtiment. Pendant que nous nous promenions dans le centre, elle m'a indiqué avec enthousiasme les principales salles où la conférence allait se dérouler. Puis, tout à coup, l'organisatrice s'est arrêtée devant une porte en bois dans un petit couloir. Elle a ouvert la porte avec respect et nous avons regardé à l'intérieur. 

C'était une pièce mal éclairée avec des meubles empilés sur les murs. "Savez-vous ce qui s'est passé dans cette pièce ?" m'a-t-elle demandé presque à voix basse. J'ai secoué la tête. Bien sûr, je n'en avais aucune idée. Elle a continué mystérieusement. "C'est ici que pendant la JAOO de l'année dernière, Kent Beck et Erich Gamma ont conceptualisé les tests unitaires et conçu JUnit."

On peut dire que c'était ma première introduction aux tests unitaires.

La nécessité des tests unitaires

L'impact de JUnit sur l'industrie du développement logiciel a été énorme. Il s'agissait du premier cadre de test unitaire viable. Par conséquent, les gens ont lentement commencé à adopter les tests unitaires. Pourtant, il a fallu beaucoup de temps pour qu'ils gagnent en popularité. Aujourd'hui encore, en 2022, lorsque je demande aux participants pendant mes discours ou à des conférences de lever la main pour savoir qui écrit les tests unitaires, beaucoup de gens ne lèvent pas la main. Et c'est bien dommage. 

Il n'y a pas si longtemps, je coachais une équipe de développement qui était complètement à l'arrêt. Ils n'osaient pas changer une ligne de code de plus, de peur que leur base de code de cinq millions de lignes ne se brise. 

Pas une seule fonctionnalité n'avait été livrée à leurs clients depuis plus de dix mois. Lorsque nous avons examiné leur base de code, nous avons trouvé quelques tests unitaires, avec un niveau de couverture de code presque inexistant, une complexité cyclomatique élevée et de nombreux chemins non testés dans le code. Et même dans cette équipe, lorsque j'ai souligné l'importance de tests unitaires solides pour maintenir la qualité et la rapidité du développement, les développeurs m'ont regardé avec des visages longs et ont demandé si l'écriture de tous ces tests était vraiment, vraiment nécessaire. 

Elle l'est.

L'écriture de tests unitaires appropriés prend du temps

Pour être tout à fait honnête, il m'a fallu un certain temps pour être convaincu des effets et des avantages des tests unitaires et, plus tard, du développement piloté par les tests. 

Pour les auteurs Kent Beck et Erich Gamma, l'objectif numéro un de la création de JUnit était "d'écrire un cadre dans lequel nous avons une lueur d'espoir que les développeurs écrivent réellement des tests". 

Ils ont construit JUnit avec des outils déjà existants et familiers, de sorte qu'il y avait peu de choses nouvelles à apprendre. Du simple Java. Comme ils l'ont dit : "Cela ne doit pas demander plus de travail que ce qui est absolument nécessaire pour écrire un nouveau test." Gamma et Beck ont rendu l'écriture de tests unitaires aussi simple que possible.

Alors pourquoi est-il si difficile de commencer à écrire des tests unitaires ? 

D'après ma propre expérience, malgré la simplicité de l'outillage, Jest étant mon poison actuel pour tester mon code TypeScript et JavaScript, un problème je pense réside dans le fait que l'écriture de tests unitaires nécessite toujours des compétences et une compréhension. 

Il faut du temps pour apprendre à écrire de bons tests unitaires. 

Et le temps est une chose dont nous manquons toujours dans le développement de logiciels. Les parties prenantes, les responsables et les Product Owners nous mettent constamment sous pression pour ajouter et améliorer les fonctionnalités de nos produits. Nous ne semblons jamais avoir de temps disponible pour travailler sur la qualité de notre architecture et de notre code. Par conséquent, nous avons tendance à négliger l'écriture de tests unitaires. 

Ne pas avoir de tests unitaires, c'est comme fumer.

Un autre défi est que les avantages d'avoir de bons tests unitaires sont récoltés à long terme. Ils ne vous apparaissent qu'après avoir maîtrisé un code de base pendant six mois à un an. La facilité et la confiance avec lesquelles vous pouvez modifier et étendre une base de code entièrement testée est une joie. Mais seulement après un certain temps.

Les gens ne sont pas doués pour se préparer aux avantages à long terme. Ne pas avoir de tests unitaires, c'est comme fumer. 

Nous savons tous que fumer est mauvais pour nous. Néanmoins, les gens ont beaucoup de mal à arrêter de fumer. Cela s'explique par le fait que les inconvénients du tabac ne se font généralement sentir que des années plus tard. Avec les tests unitaires, c'est assez similaire. 

Avoir des tests unitaires pour tout est rentable à long terme. C'est rentable au bout de six mois, lorsque vous constatez que vous pouvez modifier votre code sans difficulté. Et c'est payant au bout d'un an, lorsque vous pouvez encore modifier ce code presque sans effort et sans effets secondaires. Même après plusieurs années, votre code reste stable et est même devenu plus robuste qu'il ne l'a jamais été. 

Malheureusement, trop de gens reportent l'écriture de tests unitaires jusqu'à ce qu'il soit (trop) tard, et les conséquences de ne pas avoir de code testé sont devenues importantes. Comme pour la cigarette.

Garder votre code sain

Et cela s'aggrave lorsque vous travaillez avec des architectures logicielles modernes, telles que les microservices ou le serverless, où vous ne disposez généralement pas d'une base de code unique, mais travaillez plutôt sur une vaste collection de petites bases de code. 

Avec l'un de mes récents clients, le paysage total se composait d'une quarantaine de micro-applications, d'une cinquantaine de microservices et d'un nombre à peu près équivalent de fonctions serverless, chacune ayant ses propres bases de code, pipelines et infrastructures. Dans des environnements tels que ceux-ci, il devient encore plus critique de maintenir vos bases de code en bonne santé. 

Ne pas maintenir en bonne santé des paysages aussi complexes se traduit rapidement par la résolution sans fin de bug, la création de solutions de rechange dont personne ne se souvient le lendemain, une forte baisse de productivité, des personnes démotivées qui ne font que maintenir un code de mauvaise qualité au lieu de créer de nouvelles fonctionnalités... Et finalement un arrêt complet de l'innovation dans une organisation.

Les tests unitaires sont essentiels pour garder votre code sain.

À titre d'exemple, pendant que j'écris cet article, mon équipe et moi sommes en train d'examiner une modification mineure, mais assez délicate, de la bibliothèque centrale de la plate-forme de mon client. Cette bibliothèque contient environ quinze cents lignes de code. Une trentaine d'applications et de microservices fonctionnant en production en dépendent énormément. 

Sans même y réfléchir, nous avons effectué le changement, nous avons exécuté les trois cent quatre-vingt-cinq tests unitaires de la bibliothèque, nous avons vu qu'ils étaient tous verts et nous avons validé le code. Aucun pipeline ne s'est rompu dans le processus.

‍

Sans tests unitaires appropriés, nous n'aurions pas eu la confiance ou le courage d'effectuer un changement radical comme celui-ci. Nous l'aurions juste laissé glisser. Et nous l'aurions laissé glisser encore et encore. Jusqu'à ce que nous ne soyons plus en mesure de garantir la qualité et la maintenabilité de nos bases de code. Tout comme je l'ai vu chez tant de clients et avec tant de bases de code auparavant.

Ne remettez plus à plus tard l'écriture de vos tests unitaires

Mon conseil ? Arrêtez de vous plaindre de l'effort et du temps qu'il faut pour commencer à écrire des tests unitaires. Et arrêtez de vous plaindre que l'écriture de tests unitaires est ennuyeuse. Passez à autre chose.

Et même si les tests unitaires ne semblent pas tenir leurs promesses immédiatement, ils vous seront très utiles à long terme. C'est certain. N'attendez pas que votre code devienne impossible à maintenir. Tout comme il vaut mieux arrêter de fumer aujourd'hui que d'attendre que votre paquet soit vide, ou jusqu'au premier janvier de l'année prochaine. 

Il n'y a aucune excuse pour remettre à plus tard. 

Il est toujours préférable de commencer à écrire des tests unitaires aujourd'hui. Sérieusement ? Arrêtez de lire maintenant, et commencez à faire des tests unitaires.