Retours d'expériences de l'utilisation de Jest chez Cozy (Platformers)

RetoursExpCozyJest.md

Quelques retours d'expériences Jest

Les slides du talk Jest: https://github.com/CPatchane/jest-talk

Utilisation des snapshots

Important : le snapshoting n'est pas réservé aux tests de composants

Des snapshots pour ne pas avoir à modifier son codebase de tests à chaque fix, chaque mise à jour ou chaque changement. Les snapshots sont mis à jour et non la codebase.

Les snapshots assurent que ce qui ne doit pas bouger ne bouge pas. Intérêts à deux moments:

• Ecriture des tests : vérifier le bon resultat/rendu de tous les comportements attendus/voulus
• Execution des tests : vérifier que des ajouts ou des nouvelles features ne cassent pas les comportements ou les fonctionnalités précédemment ajoutés

Ex: create-cozy-app:

Des élements qui bougent dans le temps sans changer de sens:

• Fichiers générés via le template
• les fichiers de configs webpack mergés en fonction de différents options

Ex: cozy-app-publish

Mocking de node-fetch:

• En cas d'erreur, snapshot du message d'erreur
• En cas de succès, snapshot des informations qui allaient être envoyées vers le registry

Autres:

• Les arguments passés au helper publish
• Les messages d'erreurs (plutôt que juste tester si la fonction throw une erreur ou pas)

Autres examples

• cozy-collect: Snapshoting pour les tests de composants + tests de selectors (job, accounts...) sur des jeux de données
• cozy-store: Snapshoting sur les tests de composants et de containers (connexion de composants au store Redux)

Tests de components (via des snapshots)

Consite à tester des rendus unitaires de composants en fonction de props passées. L'important est de tester tous les comportements attendus du composants.

=> Si un comportement n'est pas "testable facilement", généralement soit il n'apparaitra jamais lors de son réel utilisation soit on peut très bien faire sans (amélioration du code grâce aux tests).

Autres fonctionnalités utiles

Vérifier que des fonctions ne throw pas d'erreurs avec les bon arguments

Examples:

• les commandes CLI build, watch, test, publish de CCA

Tester des fonction asynchrones via done()

expect(() => build({}, done)).not.toThrow()

Limites

• Les tests de composants doivent être simples, sans trop entrer dans l'architecture du composant, sinon les tests seront plus embêtants qu'efficaces.
• Les tests de composants connectés au store Redux ou la bonne application d'un HOC sont souvent peu utiles si le composant sous-jacent est déjà testé