Les 9 règles à suivre pour écrire de bons tests unitaires
Hello !
Dans les derniers mois, mon équipe et moi avons passé pas mal de temps sur l'écriture de tests unitaires pour améliorer la qualité de nos apps.
Et j'ai réalisé que malgré la formation et l'expérience de certains collègues, certaines règles cruciales à appliquer quand on code des tests unitaires n'étaient pas suivies, et parfois même pas du tout connues !
Du coup voici un petit rappel des 9 principales règles à appliquer quand on écrit des tests unitaires :
- Comprendre le code qu'on teste - ça parait évident, mais si vous ne comprenez pas le code que vous testez, vous écrirez des tests inutiles ou mauvais
- Tester tous les chemins d'exécution possible - chaque chemin d'exécution doit avoir son test unitaire, vu qu'il s'agit d'un cas (métier ou non) qui doit être géré par le code
- Vos tests doivent être indépendants - vous devez pouvoir les run dans n'importe quel ordre, et n'en lancer qu'un à la fois (sans qu'il crash car il a besoin d'un setup dans un autre test par exemple)
- Vos tests doivent être simples et rapides - run tous vos tests unitaires ne doit jamais prendre plus de quelques secondes, sinon vous avez un problème et vos TU vont devenir une contrainte plus qu'une aide à la qualité
- On ne teste qu'une couche (par exemple la couche business) et on ne dépend pas d'environnements extérieurs (par exemple la BDD) - les autres couches / environnements dont dépendent votre code doivent être systématiquement mockées
- Les noms de vos tests doivent être clairs - c'est une des règles les plus importantes. Si vous modifiez du code et qu'un test casse, vous devriez, juste en lisant le nom du test, comprendre pourquoi votre modification de code a cassé ce test. Un exemple : createAccount_withInvalidEmail_shouldThrowError
- Il est inutile de tester les méthodes passe-plat et les méthodes privées
- Intégrez vos tests à votre CI - ne dépendez pas uniquement de runs manuels
- Si écrire vos tests s'avère difficile, il faut peut-être revoir votre conception - en effet, c'est quelque chose qu'on apprend avec TDD, mais c'est pertinent en permanence : rédaction de tests compliqués = mauvais respect des principes SOLID. Vous galérez à écrire vos tests ? A priori votre code a besoin d'une refacto.
Dès que je trouverai un peu de temps, j'essaierai d'écrire un article avec des exemples complets en .Net et Typescript/Jest.
Si vous avez des questions, n'hésitez pas à demander !
Bon dev à toustes !