Jest 14.0 : Tests par instantané de l’arborescence React

Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

L'une des philosophies de Jest est de proposer une expérience intégrée "zéro configuration". Nous souhaitons faciliter au maximum l'écriture de tests pertinents et utiles. Nous avons observé que lorsque les ingénieurs disposent d'outils prêts à l'emploi, ils écrivent davantage de tests, ce qui se traduit par des bases de code stables et saines.

Une grande question ouverte était comment écrire efficacement des tests React. Il existe de nombreux outils comme ReactTestUtils et enzyme. Ces deux outils sont excellents et activement utilisés. Cependant, les ingénieurs nous ont souvent rapporté qu'ils passaient plus de temps à écrire un test qu'à développer le composant lui-même. Par conséquent, beaucoup ont cessé complètement d'écrire des tests, menant à des instabilités. Les ingénieurs nous ont expliqué qu'ils voulaient simplement s'assurer que leurs composants ne changent pas de manière inattendue.

En collaboration avec l'équipe React, nous avons créé un nouveau moteur de rendu pour les tests React et ajouté les tests par instantané à Jest. Examinez cet exemple de test pour un simple composant Link :

import renderer from 'react-test-renderer';
test('Link renders correctly', () => {
  const tree = renderer
    .create(<Link page="http://www.facebook.com">Facebook</Link>)
    .toJSON();
  expect(tree).toMatchSnapshot();
});

Lors du premier exécution, Jest crée un fichier d'instantané ressemblant à ceci :

exports[`Link renders correctly 1`] = `
<a
  className="normal"
  href="http://www.facebook.com"
  onMouseEnter={[Function bound _onMouseEnter]}
  onMouseLeave={[Function bound _onMouseLeave]}>
  Facebook
</a>
`;

L'instantané généré doit être versionné avec les modifications de code. Nous utilisons pretty-format pour rendre les instantanés lisibles pendant les revues de code. Lors des exécutions ultérieures, Jest comparera simplement le rendu produit avec l'instantané précédent. S'ils correspondent, le test réussit. Sinon, soit l'implémentation a changé et l'instantané doit être mis à jour avec jest -u, soit Jest a détecté un bogue dans votre code à corriger.

Si nous modifions l'adresse pointée par le composant Link dans notre exemple, Jest affichera ce résultat :

Vous savez maintenant que vous devez soit accepter les changements avec jest -u, soit corriger le composant si les modifications étaient involontaires. Pour tester cette fonctionnalité, clonez l'exemple d'instantané, modifiez le composant Link et exécutez Jest. Nous avons mis à jour le Tutoriel React avec un nouveau guide sur les tests par instantané.

Cette fonctionnalité a été développée par Ben Alpert et Cristian Carlesso.

Prise en charge expérimentale de React Native

En créant un moteur de rendu indépendant de toute plateforme, nous pouvons enfin prendre en charge une version complète et non mockée de React Native. Nous sommes ravis de lancer le support expérimental de React Native dans Jest via le package jest-react-native.

Vous pouvez commencer à utiliser Jest avec react-native en exécutant yarn add --dev jest-react-native et en ajoutant le préréglage à votre configuration Jest :

"jest": {
  "preset": "jest-react-native"
}

• Tutoriel et guide d'installation

• Projet exemple

• Exemple de pull request pour snowflake, une bibliothèque open source populaire pour react-native.

info

Le préréglage implémente actuellement seulement le minimum nécessaire pour démarrer avec les tests React Native. Nous comptons sur les contributions de la communauté pour améliorer ce projet. Essayez-le et signalez des problèmes ou envoyez des pull requests !

Pourquoi les tests par instantané ?

Pour les applications natives de Facebook, nous utilisons un système appelé "tests par instantané" : un système qui rend les composants d'interface, capture une capture d'écran puis compare cette capture enregistrée avec les modifications apportées par un ingénieur. Si les captures d'écran ne correspondent pas, deux possibilités : soit le changement est inattendu, soit la capture peut être mise à jour vers la nouvelle version du composant.

Si cette solution répondait à nos besoins pour le web, nous avons aussi identifié de nombreux problèmes dans les tests end-to-end que les tests d'intégration par instantané résolvent :

• Fiabilité accrue : Exécutés dans un terminal plutôt que dans un vrai navigateur ou sur mobile, le runner n'a pas à attendre des builds, lancer des navigateurs, charger des pages ou piloter l'UI pour atteindre un état attendu – sources d'aléas qui génèrent du bruit dans les résultats.

• Itérations rapides : Les développeurs veulent des résultats en moins d'une seconde plutôt qu'attendre des minutes ou des heures. Si les tests sont lents comme dans la plupart des frameworks end-to-end, ils ne les exécutent plus ou ne prennent pas la peine de les écrire.

• Débogage simplifié : Débugger un test d'intégration en JS est plus simple que de recréer un scénario de test screenshot et d'analyser les différences visuelles.

Convaincus que le snapshot testing dépasse Jest, nous avons extrait cette fonctionnalité dans un package jest-snapshot. Nous collaborons avec la communauté pour le rendre plus générique, permettant son intégration avec d'autres runners et le partage d'infrastructures.

Pour illustrer l'impact, voici le témoignage d'un ingénieur Facebook sur cette approche :

"Le plus complexe dans mon projet était de maintenir synchronisés les fichiers d'entrée/sortie de chaque test. Chaque modification fonctionnelle impliquait de mettre à jour tous les fichiers de sortie. Avec les snapshots, Jest génère gratuitement ces instantanés ! Je peux simplement vérifier les mises à jour plutôt que de les appliquer manuellement." – Kyle Davis sur fjs.

Les prochaines étapes pour Jest

Aaron Abramov a rejoint l'équipe Jest à temps plein pour améliorer notre infrastructure de tests chez Facebook. Nos priorités pour les mois à venir :

• Remplacer Jasmine : Ce socle nous ralentit et n'est plus activement maintenu. Nous remplaçons ses matchers pour introduire de nouvelles fonctionnalités et supprimer cette dépendance.

• Couverture de code : Créé avant l'ère de Babel, notre système de couverture présente des cas limites. Nous le réécrivons pour résoudre ces problèmes.

• Expérience développeur : Améliorations du processus d'installation, du débogage, du CLI et de la documentation.

• Système de mocks : Les mocks manuels sont parfois imprévisibles. Nous les rendrons plus stricts et intuitifs.

• Performances : Optimisations continues, notamment pour les très gros projets.

Comme toujours, vos questions et contributions sont les bienvenues !