Aller au contenu principal

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

· 8 minutes de lecture

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. Credit goes to first-time contributor @NullDivision for implementing this feature!

Échec d'un test interactif

Speaking of snapshots, one of the more exciting features we've shipped in recent years are Inline Snapshots, which landed in a minor release of Jest 23 almost three years ago. However, they came with the restriction that projects wanting to utilize them must be using Prettier to format their code, because that's what Jest would use to make sure the file it writes the snapshots into remains properly formatted.
And so for most of these years, we've had a pull request in the pipeline to eliminate this restriction and allow using Inline Snapshots without 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. It turns out that the dependencies we load for each test file to perform the parsing, snapshot insertion, and printing do incur a significant time and memory overhead.
So with some tricks, we've speed up the initialization per test file by roughly 70% compared to 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.

In other news, the native ESM support is progressing, but some major complexities, for instance around mocking, are still ahead of us, and we continue to observe the migration to ESM as a huge ecosystem effort, where Node and a lot of crucial tools and packages all have to rely on each other to deliver an overall compelling experience.
ESM support for plugging modules into Jest is more advanced—custom runners, reporters, watch plugins, and many other modules can already be loaded as ES modules.

We've also merged a PR to be able to deal with test files symlinked into the test directory, a feature much wanted by users of Bazel.

Another PR enabled transforms to be asynchronous, a requirement to support transpilation through tools such as esbuild, Snowpack, and Vite effectively.

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. In 2017, Aaron Abramov initially wrote a replacement for the Jasmine code called jest-circus, meant to improve error messages, maintainability, and extensibility.
After years of large-scale use at Facebook and of course in Jest itself, as well as recent adoption in create-react-app, we are now confident that jest-circus is highly compatible with jest-jasmine2 and should work in most environments with little to no migration work. 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,

and we made some TypeScript types stricter.

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.

As always, the full changelog and list of breaking changes can be viewed here.

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 ! 🃏