Jest 27 : Nouveaux paramètres par défaut pour Jest, édition 2021 ⏩

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 →

Dans le billet de blog Jest 26 publié il y a environ un an, nous annoncions qu'après deux versions majeures avec peu de changements cassants, Jest 27 activerait certains commutateurs pour définir de meilleurs paramètres par défaut pour les projets nouveaux ou pouvant migrer facilement. Cela nous permet de retirer certains paquets de la distribution par défaut de Jest 28 et de les publier plutôt comme modules installables et plugables séparément. Tous ceux utilisant les nouveaux paramètres bénéficieront d'une taille d'installation réduite, tandis que les personnes ayant besoin de ces paquets pourront toujours les installer séparément.

Avec le premier changement majeur des paramètres par défaut depuis les Nouveaux paramètres par défaut pour Jest introduits dans la version fondatrice 15, Jest 27 est désormais disponible pour garder Jest rapide, léger et pertinent à l'avenir. Nous expliquerons ces changements de paramètres par défaut et d'autres modifications cassantes notables dans cet article, mais commençons par découvrir de passionnantes nouvelles fonctionnalités !

Nouvelles fonctionnalités

Premièrement, le mode interactif que vous connaissez peut-être pour examiner et mettre à jour les snapshots en échec peut désormais aussi être utilisé pour parcourir pas à pas les tests en échec, un par un. Nous remercions le contributeur pour la première fois @NullDivision pour avoir implémenté cette fonctionnalité !

En parlant de snapshots, l'une des fonctionnalités les plus intéressantes livrées ces dernières années sont les Inline Snapshots, qui ont été intégrées dans une version mineure de Jest 23 il y a près de trois ans. Cependant, elles imposaient la restriction que les projets souhaitant les utiliser devaient employer Prettier pour formater leur code, car Jest l'utilisait pour s'assurer que le fichier dans lequel il écrit les snapshots reste correctement formaté.
Ainsi pendant la majeure partie de ces années, nous avons eu une demande d'extraction en préparation pour supprimer cette restriction et permettre d'utiliser les Inline Snapshots sans Prettier. Elle a accumulé bien plus d'une centaine de commentaires, sans même compter les demandes scindées et fusionnées au préalable, et a même changé de propriétaire une fois après la soumission initiale par un autre premier contributeur, @mmkal sous le titre de travail amusant 'Uglier Inline Snapshots'. Avec l'essor fulgurant de Prettier récemment, cette amélioration est peut-être moins nécessaire qu'en 2018, mais nous connaissons tous ce sentiment lorsqu'on rejoint un projet n'utilisant pas Prettier et où soudain les snapshots inline deviennent indisponibles. Plus jamais ça !

La principale raison ayant retardé cette intégration était, assez étonnamment, une erreur mémoire insuffisante dans notre pipeline de build. Il s'avère que les dépendances chargées pour chaque fichier de test afin d'effectuer l'analyse syntaxique, l'insertion des snapshots et l'impression engendrent un coût significatif en temps et mémoire.
Grâce à quelques astuces, nous avons accéléré l'initialisation par fichier de test d'environ 70 % par rapport à Jest 26. Notez que vous ne verrez presque certainement pas une telle amélioration de performance sur votre projet—il faudrait de nombreux fichiers de test s'exécutant très rapidement pour le percevoir, et la surcharge liée à l'utilisation d'un environnement JSDOM éclipse toute amélioration de ce type.

Ailleurs, la prise en charge native d'ESM progresse, mais certaines complexités majeures, notamment autour du mocking, persistent, et nous continuons de considérer la migration vers ESM comme un effort considérable de tout l'écosystème, où Node et de nombreux outils et paquets cruciaux doivent s'appuyer mutuellement pour offrir une expérience globale convaincante.
La prise en charge d'ESM pour brancher des modules dans Jest est plus avancée—les runners personnalisés, reporters, watch plugins et bien d'autres modules peuvent déjà être chargés en tant que modules ES.

Nous avons également fusionné une PR permettant de gérer les fichiers de test liés symboliquement dans le répertoire de test, une fonctionnalité très demandée par les utilisateurs de Bazel.

Une autre PR a permis aux transform d'être asynchrones, une exigence pour prendre en charge efficacement la transpilation via des outils comme esbuild, Snowpack et Vite.

Changement des valeurs par défaut

Jusqu'à présent, si vous utilisiez Jest dans sa configuration par défaut, vous exécutiez peut-être sans le savoir du code forké il y a plusieurs années du lanceur de tests Jasmine 2.0, qui fournit des fonctions de framework de test comme describe, it et beforeEach. En 2017, Aaron Abramov a initialement écrit un remplacement pour le code Jasmine appelé jest-circus, destiné à améliorer les messages d'erreur, la maintenabilité et l'extensibilité.
Après des années d'utilisation à grande échelle chez Facebook et bien sûr dans Jest lui-même, ainsi qu'une adoption récente dans create-react-app, nous sommes maintenant convaincus que jest-circus est très compatible avec jest-jasmine2 et devrait fonctionner dans la plupart des environnements avec peu ou pas de travail de migration. Il peut y avoir des différences mineures dans l'ordre d'exécution et la rigueur, mais nous ne prévoyons pas de difficultés majeures de mise à niveau, sauf pour le code qui repose sur des API spécifiques à Jasmine comme jasmine.getEnv(). Si vous dépendez largement de telles API, vous pouvez revenir au lanceur de tests basé sur Jasmine en configurant "testRunner": "jest-jasmine2".

L'exécution de tests dans un environnement JSDOM entraîne une surcharge de performance significative. Comme il s'agissait du comportement par défaut de Jest jusqu'à présent, sauf configuration contraire, les utilisateurs qui écrivent des applications Node, par exemple, peuvent ignorer qu'ils utilisent un environnement DOM coûteux dont ils n'ont même pas besoin.
Pour cette raison, nous modifions l'environnement de test par défaut de "jsdom" à "node". Si vous êtes affecté par ce changement parce que vous utilisez des API DOM et que vous n'avez pas configuré explicitement l'environnement de test, vous devriez recevoir une erreur lors de l'accès à document, par exemple, et vous pouvez configurer "testEnvironment": "jsdom" ou utiliser une configuration d'environnement par fichier pour résoudre ce problème.
Pour les projets mixtes où certains tests nécessitent un environnement DOM mais d'autres non, nous recommandons d'utiliser l'environnement rapide "node" par défaut et de déclarer précisément les tests nécessitant le DOM à l'aide de docblocks.
Dans la prochaine version majeure, nous prévoyons également d'éliminer jest-jasmine2 et jest-environment-jsdom de l'arbre de dépendances de Jest et de les exiger explicitement, afin que de nombreux utilisateurs puissent profiter d'une taille d'installation réduite avec moins d'éléments superflus dont ils n'ont pas besoin.

Une autre valeur par défaut que nous modifions concerne les Fausses Minuteries (Fake Timers), aussi appelées Mock des minuteries. Nous avons introduit une implémentation « moderne » optionnelle des Fausses Minuteries dans Jest 26, accessible de manière transparente via la même API, mais avec un mocking bien plus complet, par exemple pour Date et queueMicrotask.
Cette implémentation moderne des fausses minuteries sera désormais celle par défaut. Si vous faites partie des rares personnes affectées par les différences subtiles d'implémentation de manière trop importante pour migrer, vous pouvez récupérer l'ancienne implémentation en utilisant jest.useFakeTimers("legacy") ou, si vous activez les fausses minuteries globalement via la configuration, "timers": "legacy".

Fonctionnalités impliquant des changements cassants

Nous avons introduit quelques petites modifications cassantes supplémentaires pour vous aider à éviter les erreurs en interdisant certaines choses qui peuvent facilement se produire involontairement :

• Le même callback de test done ne peut pas être appelé plus d'une fois,

• appeler done et retourner une Promesse ne peuvent pas être combinés,

• un bloc describe ne doit rien retourner,

et nous avons rendu certains types TypeScript plus stricts.

Les modules utilisés dans les options de configuration suivantes sont désormais transformés comme le reste de votre code, ce qui peut être cassant si vous comptiez sur leur chargement à l'identique :

• testEnvironment

• runner

• testRunner

• snapshotResolver

Autres changements cassants

Nous avons supprimé certaines fonctions dépréciées depuis longtemps :

• jest.addMatchers (utilisez expect.extend à la place)

• jest.resetModuleRegistry (utilisez jest.resetModules à la place)

• jest.runTimersToTime (utilisez jest.advanceTimersByTime à la place)

De nombreux paquets de Jest ont migré vers des exports de type ESM (bien qu'ils soient toujours livrés en CommonJS), donc si vous utilisez directement par exemple pretty-format, vous devrez peut-être ajuster votre import vers un import default.

Nous avons abandonné le support de Node 13 - mais Jest supporte toujours les versions Current et toutes les versions LTS de Node, et Jest 27 continue de supporter Node 10, qui n'est plus maintenu que récemment.

Comme toujours, le changelog complet et la liste des changements cassants peuvent être consultés ici.

Enfin, nous remercions la communauté qui a une fois de plus attribué à Jest une satisfaction record de 96% dans le sondage State of JS 2020 ! Prenez soin de vous, et nous espérons que vous continuerez à apprécier Jest dans les années et versions à venir ! 🃏