Une bonne recette pour tester les composants React
React & Composants Partie II
Nous avons vu dans la première partie le découpage que j’utilise pour les composants React. Nous allons voir aujourd’hui, ce que cela apporte à ma gestion des tests.
Pour mes tests, j’utilise, depuis maintenant un petit moment, l’excellente librairie de Kent C. Dodds (ce nom ne doit pas vous être inconnu, surtout si vous lisez mes articles) : Testing Library.
La vue
On commence direct par ce qui fâche : les snapshots. Il y a clairement deux écoles. Une pour, et une totalement opposée. En ce qui me concerne, je trouve que bien utilisé, ils peuvent s’avérer efficace.
- ✅ Ils sont rapides et faciles à mettre en place.
- ✅ Ils testent exactement ce qu’on attend, de façon globale.
- ✅ Ils peuvent détecter une modification de composant externe et alerter le développeur. (On modifie un petit composants, tous les composant l’utilisant échouent, on peut donc en vérifier l’impact)
- ✅ Ou ils peuvent, au contraire, ne se concentrer que sur le composant en lui même en mockant ce qui est est externe. (Un toolkit par exemple)
Cependant, il y a des règles strictes à respecter pour qu’ils ne soient pas de simples écrans de fumée.
Les choses à éviter sont :
- 🚫 Se baser uniquement sur des snapshots (Sauf sur des composants très simples où il peut s’avérer suffisant)
- 🚫 Remplacer une assertion stricte par un snapshot (on ne teste jamais le container avec un snapshot)
- 🚫 Mettre à jour bêtement les snapshots dès qu’ils échouent. Tout comme on ne corrige pas bêtement un test qui échoue.
- 🚫 Utiliser les snapshots pour augmenter sa couverture de code
Une vue complexe doit être testée également avec des assertions strictes. Un bouton actif, un message d’erreur affiché méritent des assertions. Cela correspond a des use-cases spécifiques et doivent être testés séparément et explicitement. On pourra utiliser Jest Dom pour plus de facilité.
Mieux vaut ne pas utiliser les snapshot que mal les utiliser. Sinon ils donnent un sentiment illusoire de sécurité.
Les Hooks et les fonctions pures
Dans le fichier de hooks, nous pouvons trouver deux sortes de fonctions : des fonctions pures, et des hooks. Ils peuvent, au besoin et de façon judicieuse, être dans des fichiers séparés.
Les fonctions pures se testeront très facilement avec Jest et de simples assertions. (La joie des fonctions pures).
Pour le second groupe nous allons utiliser React hooks testing library.
Cette librairie va permettre de tester séparément les hooks de notre composant.
Le container
Une application bien organisée contiendra des hooks (la logique) et le composant pur (la vue). Le container sera le ciment entre eux et aura la tâche importante de lier la logique à la vue en y injectant les dépendances. Ainsi, le container peut ne faire que quelques lignes.
Bon nombre de développeurs serait tenter de faire l’impasse sur les tests du container, comme nous ne testions pas le Compose lorsque nous utilisions Recompose, ou feront un simple render pour tromper le coverage. Alors que c’est précisément le composant dans son ensemble (vue + logique) que nous devons tester.
A travers les tests unitaires des fonctions logiques, des hooks et de la vue, nous allons augmenter la couverture de code.
A travers les tests du container nous allons augmenter la couverture des cas.
Et c’est en fin de compte ce qui compte le plus : savoir que l’application fait toujours ce qu’on attend d’elle.
Nous allons donc effectuer ici les tests d’intégration. Ce sont eux qui vont garantir le bon fonctionnement du composant. Ils seront également très résistants à la refactorisation de code.
Bonus : Provider
Dans mon premier article sur React, je parlais de gérer son état React. Jusqu’ici nous couvrons des cas simples, mais en l’apportant à ce premier article il nous manque une chose à tester : Le provider.
Ce dernier n’est pas facile à tester. Nous n’avons pas vraiment d’interface type hook à tester, ou de rendu graphique à manipuler. Pour le tester il faut donc en créer un puis le manipuler.
De là il ne reste plus qu’à le tester.
TADAAAM
Sans tricher, sans se forcer et en excluant simplement l’index.js :
Conclusion
Ici nous sommes dans un cas simple, on ne teste qu’un composant, et on vient de voir qu’il est très facile de le tester à 100%.
Je n’ai absolument pas chercher à couvrir totalement mon code, et avec la moitié de mes tests je peux atteindre pas loin des 100% de coverage. Mais le but ici était de couvrir les cas d’utilisations.
En couvrant les cas et non le code, on va se retrouver avec un filet bien plus solide, plus rassurant et surtout resistant à la refactorisation de code.
Enfin, sur un projet plus complexe, ne cherchez pas à parfaire le coverage, c’est totalement contre productif (lisez ceci ou encore ça). Couvrez les cas.
🍺 Si vous appréciez l’article, un petit clap, un petit partage ça fait toujours plaisir 🍺
Prochaines parties à suivre :
- 👉 Partie III : Améliorer son accessibilité
- 👉 Partie IV : Dojo React testing Library
