Jest 27 : nouvelles valeurs par défaut pour Jest, édition 2021 ⏩

Dans l'article du blog pour Jest 26, il y a environ un an, nous avons annoncé qu'après deux versions majeures avec peu de modifications de rupture, Jest 27 basculera quelques interrupteurs afin de définir de meilleures valeurs par défaut pour les projets qui sont nouveaux ou qui peuvent migrer en douceur. Cela nous donne l'opportunité de retirer certains paquets de la distribution par défaut de Jest 28 et de les publier en tant que modules installables et connectables séparément. Tous ceux qui utilisent les nouvelles valeurs par défaut peuvent bénéficier d'une installation plus petite, tandis que ceux qui ont besoin de ces paquets peuvent toujours les installer séparément.

Avec le premier changement majeur des valeurs par défaut depuis les nouvelles valeurs par défaut pour Jest qui accompagnaient la version 15, Jest 27 est maintenant là, pour que Jest reste rapide, léger et pertinent dans le futur. Nous expliquerons ces changements de valeurs par défaut et d'autres changements notables dans cet article, mais tout d'abord, nous allons aborder les nouvelles fonctionnalités !

Mises à jour des fonctionnalités

Tout d'abord, le mode interactif que vous connaissez peut-être pour examiner et mettre à jour les snapshots en erreur peut désormais être utilisé pour passer les tests en erreur un par un. Le mérite revient au premier contributeur @NullDivision pour l'implémentation de cette fonctionnalité !

En parlant de snapshots, l'une des fonctionnalités les plus intéressantes que nous ayons livrées ces dernières années est celle des snapshots en ligne, qui ont débarqué dans une version mineure de Jest 23 il y a presque trois ans. Cependant, ils sont arrivés avec la restriction que les projets voulant les utiliser doivent utiliser Prettier pour formater leur code, car c'est ce que Jest utilisait pour s'assurer que le fichier dans lequel il écrit les snapshots reste correctement formaté.
Et donc, pendant la plupart de ces années, nous avons eu une pull request dans le pipeline pour éliminer cette restriction et permettre d'utiliser les snapshots en ligne sans Prettier. Elle a accumulé plus d'une centaine de commentaires, sans même considérer les PR qui s'en sont détachées et ont atterri en premier, et elle 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 hilarant « Uglier Inline Snapshots » (« Snapshots en ligne hideux »). Avec l'ascension fulgurante de Prettier ces derniers temps, cette amélioration est maintenant peut-être moins nécessaire qu'en 2018, mais tout de même, nous connaissons ce sentiment de se retrouver dans un projet qui n'utilise pas Prettier, et de ne plus pouvoir soudainement utiliser les snapshots en ligne. Plus jamais ça !

La raison principale pour laquelle il nous a fallu tant de temps pour réaliser ce projet était, de manière assez surprenante, une erreur de mémoire dans notre pipeline de construction. Il s'avère que les dépendances que nous chargeons pour chaque fichier de test afin d'effectuer l'analyse syntaxique, l'insertion de snapshot et l'affichage entraînent effectivement un surcoût important en termes de temps et de mémoire.
Ainsi, avec quelques astuces, nous avons accéléré l'initialisation de chaque fichier de test d'environ 70% par rapport à Jest 26. Notez que vous ne verrez certainement pas une telle amélioration des performances sur votre projet - vous auriez besoin de beaucoup de fichiers de test qui s'exécutent chacun très rapidement pour mieux le remarquer, et la surcharge lors de l'utilisation d'un environnement JSDOM éclipse une telle amélioration.

Autres nouvelles, la prise en charge native d'ESM progresse, mais certaines complexités majeures, par exemple autour de la simulation, sont encore en cours, et nous continuons à observer la migration vers ESM comme un énorme effort d'écosystème, où Node et beaucoup d'outils et de paquets cruciaux doivent tous compter les uns sur les autres pour offrir une expérience globale convaincante.
Le support ESM pour le branchement de modules dans Jest est plus avancé - les exécuteurs personnalisés, les rapporteurs, les plugins de surveillance et de nombreux autres modules peuvent déjà être chargés en tant que modules ES.

Nous avons également fusionné une PR pour pouvoir traiter les fichiers de test liés par un lien symbolique au répertoire de test, une fonctionnalité très souhaitée par les utilisateurs de Bazel.

Un autre PR a permis aux transforms d'être asynchrone, une exigence pour prendre en charge efficacement la transpilation via des outils tels que [esbuild](https://esbuild. github.io/), Snowpack, et Vite.

Inversion 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 - un code forké il y a plusieurs années à partir de l'exécuteur de tests Jasmine 2.0 qui fournit des fonctions de framework de test telles que describe, it, et beforeEach. En 2017, Aaron Abramov a initialement écrit un remplacement du 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 que l'adoption récente dans create-react-app, nous sommes maintenant confiants que jest-circus est hautement compatible avec jest-jasmine2 et devrait fonctionner dans la plupart des environnements avec peu ou aucun 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 autres que pour le code s'appuyant sur des API spécifiques à Jasmine telles que jasmine.getEnv(). Si vous vous appuyez largement sur de telles API, vous pouvez opter à nouveau pour le gestionnaire de tests basé sur Jasmine en configurant "testRunner" : "jest-jasmine2".

L'exécution de tests dans un environnement JSDOM entraîne un surcoût de performance non négligeable. Parce que c'était le comportement par défaut de Jest, sauf configuration contraire jusque-là, les utilisateurs qui écrivent des applications Node, par exemple, peuvent ne même pas savoir qu'ils reçoivent un environnement DOM coûteux dont ils n'ont même pas besoin.
Pour cette raison, nous allons changer l'environnement de test par défaut de "jsdom" à "node". Si vous êtes affecté par ce changement parce que vous utilisez les API DOM et que l'environnement de test n'est pas explicitement configuré, vous devriez recevoir une erreur lorsque par exemple document est accédé, et vous pouvez configurer "testEnvironment" : "jsdom" ou utiliser la configuration de l'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 exactement les tests qui ont besoin du DOM en utilisant des 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 d'exiger qu'ils soient installés explicitement, afin que de nombreux utilisateurs puissent profiter d'une taille d'installation plus petite avec moins de superflu.

Une autre valeur par défaut que nous changeons affecte les faux temporisateurs alias les simulateurs de temporisation. Nous avons introduit une option d'implémentation « moderne » de faux temporisateurs dans Jest 26 accessible de manière transparente via la même API, mais avec une simulation beaucoup plus complète, notamment pour Date et queueMicrotask.
. Cette implémentation moderne de faux temporisateurs sera désormais la valeur par défaut. Si vous faites partie des quelques malchanceux qui sont trop lourdement affectés par les subtiles différences d'implémentation pour migrer, vous pouvez récupérer l'ancienne implémentation en utilisant jest.useFakeTimers("legacy") ou, si vous activez les faux temporisateurs globalement via configuration, "timers" : "legacy".

Fonctionnalités à venir avec des changements de rupture

Nous avons introduit quelques petits changements de rupture 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 être appelé plus d'une fois,
• l'appel à done et le retour d'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 une rupture si vous comptez sur leur chargement tel quel :

• testEnvironment
• runner
• testRunner
• snapshotResolver

Divers changements de rupture

Nous avons supprimé certaines fonctions, obsolètes depuis longtemps :

• jest.addMatchers (utilisez expect.extend à la place)
• jest.resetModuleRegistry (utilisez jest.resetModules à la place)
• jest.runTimersToTime (utilisez jest.advanceTimersByTime à la place)

Beaucoup de paquets de Jest ont été migrés pour utiliser des exportations de style ESM (bien qu'ils soient toujours livrés en tant que CommonJS), donc si vous consommez par exemple pretty-format directement, vous devrez peut-être ajuster votre import en un import default.

Nous avons abandonné la prise en charge de Node 13, mais Jest prend toujours en charge les versions Current et toutes les versions LTS de Node et Jest 27 continue de prendre en charge Node 10, qui est tombé en désuétude que récemment.

Comme toujours, le changelog complet et la liste des changements de rupture peuvent être visualisés ici.

Enfin, nous tenons à remercier la communauté qui, une fois de plus, a accordé à Jest un taux de satisfaction exceptionnel de 96 % dans l'enquête State of JS 2020 ! Soyez prudents, et nous espérons que vous continuerez à utiliser Jest avec plaisir dans les années et versions à venir ! 🃏