Comment testez-vous les composants React, et que choisissez-vous délibérément de ne pas tester ?

Testez le comportement à travers la même surface que l'utilisateur : rendez le composant, interrogez par rôle et nom accessible, interagissez, et vérifiez ce qui apparaît. Couvrez la logique qui peut vraiment casser, comme le rendu conditionnel, les états d'erreur et vides, et les hooks personnalisés. Ne testez pas les détails d'implémentation comme l'état interne, le passage de props ou le fait qu'un composant enfant a été appelé ; ces tests cassent à chaque refactorisation et n'attrapent rien.

Ma règle, c'est qu'un test ne doit échouer que quand le comportement visible par l'utilisateur change. Donc je rends le composant avec Testing Library, j'interroge par rôle et nom accessible, je clique et je tape comme le ferait une personne, et je vérifie ce qui est à l'écran. Ça a un effet de bord agréable : si je n'arrive pas à l'interroger par rôle, le markup a en général un problème d'accessibilité. Pour le réseau, j'intercepte au niveau HTTP plutôt que de mocker ma propre couche de données, parce que mocker mon propre module revient à tester mon mock. L'essentiel de la valeur vient de la couche intermédiaire : une fonctionnalité entière rendue avec ses vrais enfants et un faux serveur, plutôt qu'un test par composant. Ce que je ne teste pas, c'est l'état interne, le fait qu'un utilitaire a été appelé, les fichiers de snapshot d'un arbre entier, ou le style. Tout ça casse sur des refactorisations inoffensives et passe pendant que quelque chose est réellement cassé. Ensuite un petit nombre de tests bout en bout couvre les parcours que l'entreprise ne peut pas se permettre de casser, comme l'inscription et le paiement, et c'est tout.