Écris tes tests unitaires !

Illustration de Céline P.

Maintenant qu'on code, on va vouloir produire un code de qualité, un code robuste, sans bug, qui fonctionne comme prévu et qui ne va pas nous péter dans les doigts à la première modification.

Un peu de contexte

Ça fait maintenant 5 ans que je travaille dans le domaine du développement web, j'ai eu l'occasion de travailler avec plusieurs équipes, sur plusieurs projets, mais aucune de ces équipes n'avait pour habitude d'écrire des tests. Même pas des tests unitaires.

La plupart de ces équipes étaient effrayées d'en écrire, ne maîtrisant pas le sujet, pensant que cela ferait perdre du temps. Ils utilisaient parfois des cahiers de tests, qui n'étaient fait que rarement, car retester toute l'application à la main avant chaque release prends énormément de temps, surtout si vous travailler en méthode agile et que vous devez livrer toutes les deux ou trois semaines.
La plupart du temps on livrait notre code sans s'assurer que toute l'application fonctionnait correctement.

Je ne vais pas vous cacher que ça nous arrivait souvent de casser des fonctionnalités en production à cause d'effets non prévus.

Cependant, écrire des tests unitaires est important. La qualité de votre produit en dépend. Un code qui n'est pas testé est un code qui va casser. Peut-être avez-vous entendu parler du Test Driven Development (TDD), c'est une superbe méthode de développement qui vaut vraiment le coup de s'y intéresser mais qui demande une petite phase d'adaptation j'y accorderait peut être un article plus tard mais pour le moment, concentrons nous sur les tests en eux-même.

Comment qu'on teste ?

Toute application doit être testée, afin de s’assurer que ce qu’on produit fonctionne.
La première approche face aux tests est le test manuel ; vous exécutez votre code et regardez s’il fonctionne.
Cependant, plus votre projet grossit et plus il devient long et difficile de tester uniquement la partie sur laquelle vous travaillez - vous allez en effet souvent devoir effectuer plusieurs actions pour arriver à l’endroit où vous avez écrit vos modifications -
Pour être certain que tout fonctionne il faudra retester toute l’application avant chaque mise en production, c’est une tâche répétitive et pas drôle.

Heureusement pour nous, nous avons la possibilité de créer des programmes spécifiques pour tester notre application. C’est ce qu’on appelle des tests automatisés.

Les tests automatisés

Si vous regardez la pyramide de tests ci-dessous, on peut voir 3 types de tests, chacun avec des avantages et des inconvénients.

Test unitaire

La base de la pyramide constitue les tests unitaires, vous allez tester des parties isolées de votre code (une classe, une fonction) et créer des substituts pour tout ce dont ce code dépend. Ils sont rapides à exécuter, vite rentable car vous ne les écrivez qu’une fois, mais seront exécutés de nombreuses fois C’est LE MINIMUM ! Car prennent peu de temps et coûtent pas cher.

Test d’intégration

Ces tests reproduisent plus la réalité que les tests unitaires puisqu’on va tester l’application complète en prenant en compte son environnement (base de données, services extérieurs, ...) on va pouvoir tester si tout fonctionne bien ensemble.

Test fonctionnel

Là on va vraiment tester des fonctionnalités complètes de l’application comme se connecter ou créer un article - si vous testez votre blog - avec des tests de bout en bout ou des outils comme Selenium. Ces tests sont les plus longs à mettre en place, mais vous allez pouvoir vraiment tester les mêmes fonctionnalités que vos utilisateurs finaux. Si vous avez des testeurs QA avec vous tant mieux ! Car c'est souvent leur tâche de faire ces tests. Sinon, dommage...

Bon ça à l'air pas mal tout ça, mais ça commence à faire beaucoup et on n’a pas envie de mettre un mois à implémenter des tests avant de livrer une feature.

Et oui, créer des tests automatiques ça peut être long, c'est pour ça qu'on ne va s'intéresser qu'aux tests unitaires qui sont très rapides à faire une fois qu'on a compris le principe et offre tous les avantages pour garder un code propre et prévisible.

Avantages des tests unitaires

S'assurer que son code fonctionne comme on s'y attend ✔️

Tout d'abord ça va nous permettre de tester à fond les fonctions qu'on écrit, pour s'assurer qu'elles fonctionnent comme prévu. On écrit des tests pour tester, logique.

Éviter la régression de code 📈

L'ajout de nouvelles fonctionnalités peut introduire des bugs à des endroits inattendus, vous ne pouvez pas tout prévoir, il peut y avoir des effets de bord.

Avec les tests unitaires, vous allez pouvoir faire ces changements avec plus de confiance. Ne serait-ce pas génial de pouvoir faire vos modifications, et savoir si vous n'avez pas introduit de bug immédiatement, simplement en pressant un bouton ? Les tests unitaires sont là pour ça. En plus, si vous utilisez un VCS tel que git, vous allez pouvoir lancer vos tests dans un CI, balancer vos rapports de tests à des outils comme SonarQube, et frimer en montrant votre test coverage et l'évolution de vos tests.

Le temps ⏰

Il y a de nombreux types de tests. Tests d'intégration et tests de bout en bout prennent effectivement du temps, mais les tests unitaires sont les plus rapides à mettre en place. Pensez-vous qu'écrire des tests unitaires prend du temps ? En vérité ça aurait tendance à vous en faire gagner. Effectivement, on va écrire plus de code, mais écrire des tests va vous forcer à vous poser les bonnes questions sur votre code et prévenir des bugs. On va revenir moins souvent sur notre code parce qu'il aura déjà été testé. Sur le long terme je vous assure que vous gagnez du temps.

Reprise de code 👨🏽‍💻

Souvent on va devoir travailler sur du code qu'on n'a pas écrit nous-même. Les tests unitaires vont nous permettre de découvrir ce code et de savoir comment il réagit. Dans le cas où les tests n'existent pas, les écrire nous même nous permettra de découvrir le code.

Meilleur code 💪🏼

Vous allez éviter de créer des fonctions énormes avec énormément de dépendances, car elles sont plus difficiles à tester. Ça tombe bien pour vos pairs parce qu'elles sont plus difficiles à comprendre aussi. L'écriture de tests unitaires incite à mieux découper ses fonctions, les rendre plus courtes ; une fonction ne devrait faire qu'une chose et le faire bien. Elles seront plus compréhensibles, auront moins paramètres. Bref vous aurez un code plus propre.

Il faut que je vous mette en garde, un manque de tests unitaires est source de dette technique et pourrait avoir de graves conséquences sur votre projet : frustration, démotivation et refonte du projet de zéro.

Le piège ⚠️

Et oui il y a un piège ! Maintenant que vous savez que les TU c'est utile, vous vous dites peut-être “Ouai j’ai pigé le truc, mais je vais continuer à tester à la mano et j’ajouterais des TU plus tard”.
SURTOUT PAS ! Les TU sont hyper simples à faire en début de projet quand votre projet n’est qu’une vaste prairie vierge, mais peuvent devenir un cauchemar si vous les implémentez plus tard, que vous avez tout déclarer de manière globale, et que vous vous baladez des dizaines de dépendances partout dans votre code. Je vous l’ai dit : écrire des TU va vous inciter à écrire un meilleur code.

Faut-il écrire des tests partout, tout le temps ?

Il faut avant tout se poser les bonnes questions. Personnellement je n'écris pas des tests tout le temps. Ce blog pourrait avoir des tests, mais ce n'est pas le cas, car il intègre assez peu de logique, j'estime que les éléments dynamiques sont et resteront prédictibles. Et je compte sur vous pour me remonter les bugs en commentaire 😉
Mais dans mon travail et sur mes applications, je m'efforce d'écrire des tests souvent, surtout lorsqu'il s'agit d'applications critiques qui seront utilisées par d'autres personnes que moi.
Des tests sur toutes les fonctions, sur tous les cas que j'imagine.
Si vous débutez, je vous conseille d'écrire des tests partout, ça vous fera un bon exercice et vous pourrez acquérir une vision sur les tests et vous faire votre propre avis.

Conclusion

Voilà un bon résumé. Les tests unitaires apportent beaucoup d'avantages et aucun inconvénient. Grâce à eux vous améliorez votre code, vous allez aller plus vite et vous vous améliorez, vous aussi.

Vous avez vu qu'on ne peut pas s'en passer, maintenant on code ! ... Dans un prochain article 😁