Nous voila dans la suite de l’article de la gestion de la dette technique. Aujourd’hui nous allons parler du point sur les tests unitaires.
Les tests unitaires, vous en avez probablement entendu parler notamment de phpUnit. L’intérêt des tests unitaires est multiple, mon intention ici n’est clairement pas de vous apprendre à faire des tests unitaires mais de rappeler leur intérêt et surtout comment les mettre en place intelligemment.
Rappel, un test unitaire sert à tester une fonction précise unique avec un périmètre défini. Prenons par exemple une fonction que nous nommerons “somme” qui prendra en paramètre deux nombres et qui en retourne la somme. Le périmètre est restreint simple à tester. La fonction parait même simpliste et on pourrait se demander pourquoi la tester. Plusieurs raisons :
- Ça ne prend pas énormément de temps
- Vous aurez l’esprit serein quand vous aurez besoin de modifier cette fonction
- Si ce test ne passe pas et que tout s’écroule vous trouverez rapidement le coupable
Les tests unitaires ne sont pas la pour vous ennuyer ou vous ralentir, mais pour vous apporter une sérénité et un confort de travail. C’est un des points les plus importants des tests unitaires. Vous obtiendrez un retour sur votre travail quasi instantanément. C’est ce retour qui fait que vous avez l’esprit serein.
Prenons un exemple simple, sans test unitaire, vous faites vos modifications, vous vous perdez dedans parce que vous êtes trop confiant, et quand vient l’exécution du code, c’est l’erreur fatale. S’en suit alors une série de ctrl+z ou des var_dump et die en tout genre.
Avec des tests unitaires c’est simple, vous faites vos modifications, vous vous perdez dedans parce que vous êtes trop confiant, et quand vient le passage des tests unitaires, …, vous savez exactement ce qui ne marche pas.
A l’instar d’un correcteur orthographique qui vous dit quand vous tapez si vous avez fait une faute et où vous avez la même chose avec les tests unitaires. Vous vous passeriez sérieusement du correcteur orthographique sur votre PC ?
L’autre point c’est que les tests unitaires prennent fatalement du temps au moment des les réaliser. Autant les prévoir, et avancer avec plus de sérénité pour le futur. Mais bon ce temps représente un coût et vous ne pouvez pas forcement vous le permettre. Alors quoi tester ?
Nous avons pris parti avec mon équipe de tester systématiquement deux éléments :
- Tous les services qui sont fournis à des tiers
- Toutes les briques que nous réutilisons en interne
Pourquoi uniquement ces deux points là et pas tout ? Parce que nous n’avons pas le temps, et surtout que tout tester n’est pas forcément pertinent. Par exemple certaines applications événementielle qui vont être jeter au bout de deux semaines nous faisons l’impasse. Le retour sur investissement ne vaut pas le coût.
Nous testons les services fournis aux tiers, pour la simple et bonne raison que nous n’allons pas fournir un service défaillant à des tiers liés uniquement à des modifications de notre part. C’est une question de respect à mon sens. Quand vous payez un service vous ne souhaitez pas que votre fournisseur vous disent : “Ah oui ça marche plus mais c’est parce qu’on a fait des modifications, on est désolé on va réparer ça rapidement, …. bla bla bla”. Vous voulez que ça marche un point c’est tout. Donc on s’y engage.
Nous testons les briques que nous réutilisons, par exemple, nous avons des briques internes qui sont réutilisées à travers toutes nos applications. Celles ci par moyen d’y couper on teste. C’est logique si on a une erreur elle sera multipliée par le nombre de projet. Ça relève plus du bon sens que d’autre chose. D’autant plus que ces briques sont énormément utilisées et complexes, rejouer tous les tests à la main ou penser à tout vérifier est impossible. Alors qu’exécuter les tests unitaires ça prend quelques secondes (un peu plus car on en a quelques centaines voire quelques milliers sur certains projets).
Pour le reste, on ne teste pas unitairement notre backoffice par exemple, parce qu’on n’y voit pas l’intérêt, nous avons moins de 10 utilisateurs dessus, quand ça pète ils s’en rendent compte dans l’environnement de recette et ça ne fait de mal à personne. On corrige, ils vérifient, ça part en prod.
Bref, à mon sens tout tester n’a pas forcément de sens, mais tester est indéniablement un atout pour la tranquillité des équipes et la pérennité du code.