L’écriture des tests est primordiale dans un projet qui recherche une fiabilité, une maintenabilité et surtout pour distribuer des versions avec confiance ! Faisons le tour des tests en React Native et React JS.
Il existe trois types de tests :
Les tests unitaires
⟩ Ce sont des tests atomiques
⟩ Ils sont rapides à exécuter
⟩ Généralement ils servent à tester une seule chose
⟩ Leur quantité reflète la modularité de l’application
⟩ Par exemple, on teste que notre réducteur modifie correctement le state avec une action donnée
Les tests d'intégration
⟩ Ils servent à interagir avec des procédures ou des composants
⟩ À la manière des tests unitaires, ces tests sont relativement isolés, mais plutôt par rapport à la fonctionnalité
⟩ Par exemple, on teste un composant « Modal », on teste le comportement de la modale, on vérifie les propriétés, le state, etc.
Les tests d'acceptance
⟩ Ce sont les plus longs à exécuter, mais ils sont également bien moins nombreux
⟩ Ils servent à tester l’application sur un processus
⟩ Ils contiennent un niveau d’abstraction: on ne teste pas la logique interne mais le comportement de l’application
⟩ Par exemple, on va tester le processus de login entier comme si c’était un utilisateur qui utilise l’application
Et aujourd’hui nous avons des outils qui nous permettent d’automatiser ces trois types de tests dont voici quelques librairies utiles pour chacun des tests en React Native et React JS :
Pour les tests d’intégration
Pour les tests unitaires
Pour les tests d’acceptances
Kent.C Dodds a fait une conférence sur les tests, et son approche des tests React est tout à fait louable : il parle de différentes répartitions entre les trois types de tests. En ce qui concerne les apps React JS et React Native, d’après Kent.C Dodds, ce serait le « testing-trophy ». C’est-à-dire :
Environ 15% de tests d'acceptances
Environ 50% de tests d'intégration
Environ 35% de tests unitaires
Il a également souligné durant sa présentation le fait que pour les tests il y a une sorte de “front de pareto”. C’est-à-dire qu’au-delà d’un certain pourcentage de couverture de tests, le ROI des tests serait relativement bas.
Il est important pour chaque équipe de bien placer ce « front de pareto » pour déterminer la bonne quantité de tests à développer, sans faire décliner la vélocité de l’équipe, ni compromettre la qualité de l’application. Bien sûr cela implique de tester ce qui est critique, là où on soupçonne les régressions d’apparaître, les processus importants.
Je terminerai ce billet par une note sur les snapshots. C’est un des types de tests à choisir en dernier. Ils sont utiles pour traquer des différences après des modifications sur des petits composants, qui ne sont que des « composants à état », mais il ne faut pas compter sur ce type de tests pour éviter les régressions ou encore mettre au jour des dysfonctionnement ou des bugs.
