Jest 25 : 🚀 pose des fondations pour le futur

Jest 25 pose les bases de nombreux changements majeurs à l'avenir. Nous avons donc limité au maximum les changements de rupture, mais les modifications de l'architecture interne peuvent nécessiter une attention particulière pendant la mise à niveau. Les principaux changements sont une mise à niveau de JSDOM de la v11 à la v15, des tests 10-15% plus rapides, une nouvelle vue diff pour les instantanés périmés et l'abandon du support de Node 6.

There has been more than 200 commits since Jest 24.9 by more than 80 different contributors, so as always, take a look at the changelog for a full list of changes.

Au revoir Node 6

Node 6 est en fin de vie depuis le 30 avril 2019, et Jest 25 le laisse derrière lui. L'abandon de Node 6 signifie que nous pouvons mettre à jour nos dépendances, la principale étant JSDOM, qui a été mise à jour à la version 15. La mise à niveau signifie également que nous ne devons plus transpiler la syntaxe async-await, ce qui se traduit à la fois par une exécution plus rapide du code et une moindre consommation de mémoire. En prime, le code transpilé de Jest devrait être plus facile à déboguer si quelqu'un se retrouve à dévaler cette pente.

Même si Node 8 est également entré en fin de vie, Jest 25 continuera à le prendre en charge afin de rendre la mise à niveau aussi facile que possible pour ceux d'entre nous qui prennent encore en charge Node 8. Elle s'accompagne cependant de quelques compromis, comme le fait que JSDOM v16 a été publié sans le support de Node 8, vous devrez donc utiliser jest-environment-jsdom-sixteen si vous voulez utiliser la dernière version.

Améliorations des performances

Nous avons reçu des rapports indiquant que Jest a ralenti au cours des deux dernières versions. Jest 25 comprend une mise à jour de Micromatch, qui apporte des gains énormes en temps de démarrage, et quelques corrections de bogues et ajustements de performance qui ramène Jest à la vitesse à laquelle il était pour Jest 23. Pour Jest lui-même, comme mentionné au début de cet article, cela signifie une réduction de 10-15% du temps d'exécution des tests. Bien entendu, nous cherchons toujours à nous améliorer, alors n'hésitez pas à comparer les résultats avec ceux des versions précédentes et à signaler les problèmes qui pourraient survenir !

Couverture de code V8

L'instrumentation de couverture de code actuelle de Jest est alimentée par babel-plugin-istanbul qui insère du code de collecte de couverture de code avant de créer des rapports. Cependant, cette méthode est assez lente et gourmande en mémoire, surtout pour les fichiers et les bases de code volumineux. Heureusement, V8 a une couverture de code intégrée, qui devient de plus en plus utilisable dans Node grâce au travail acharné de Benjamin Coe et d'autres membres des équipes V8 et Node.js. Jest 25 est livré avec un support expérimental pour cela via un nouveau drapeau --coverage-provider. Veuillez consulter sa documentation pour les avertissements et la façon de l'utiliser.

Penser vite et lentement quand les tests échouent

Les efforts inutiles pour interpréter les rapports en cas d'échec des tests sont un frein :

• « penser rapidement » pour reconnaître les modèles de votre expérience passée
• « penser lentement » pour analyser les changements et décider s'il s'agit de progrès attendus ou de régressions inattendues

Jest 25 achève la seconde moitié d'un effort commencé en Jest 24 pour améliorer tous les comparateurs :

• une ligne de description correcte, y compris les modificateurs .rejects, .resolves et .not
• des libellés concis et un alignement uniforme pour les valeurs attendues et reçues
• inverse la mise en évidence des différences de sous-chaînes lorsque attendu et reçu sont des chaînes de caractères
• nombre de lignes modifiées dans les différences pour savoir si c'est seulement des suppressions ou des insertions

Nous remercions tout particulièrement le mainteneur de Jest Mark Pedrotti pour avoir piloté cet effort et son travail continu pour rendre les erreurs d'expectation aussi satisfaisantes que possible.

Couleurs des différences lorsque les tests de snapshot échouent

Le changement le plus évident pour remplacer la confusion par la confiance est la couleur des lignes de changement dans les différences lorsque les tests snapshot échouent :

• - Snapshot passe du vert au magenta
• + Received passe du rouge au bleu sarcelle sur fond cyan/aqua

Exemples de rapports de tests (avant à gauche et après à droite)

1. Le nombre de lignes modifiées confirme votre première impression : dans quel sens le snapshot a-t-il changé (c'est-à-dire, lignes supprimées ou insérées)

2. Les couleurs de fond attirent vos yeux pour comparer les lignes modifiées adjacentes

3. Les couleurs de fond vous aident également à voir quels tests toThrow nécessitent une décision sur la mise à jour ou non du snapshot

Voici quelques raisons pour lesquelles nous avons choisi des couleurs uniques :

• Pour 95 % des personnes qui ont une vision complète des couleurs, elles peuvent reconnaître rapidement les rapports provenant de tests snapshot par rapport à tous les autres comparateurs.
• Cela résout le conflit direct entre la signification du vert/rouge dans les tests Jest et le rouge/vert dans la révision du code.
• Contrairement à l'inversion rouge/vert qui suggère que la mise à jour est la décision par défaut, ceci suggère que les différences nécessitent un examen plus attentif pour une éventuelle régression dans les échecs des tests snapshot locaux que dans la révision du code (lorsque les problèmes ont déjà été corrigés).

La différence de teinte entre le magenta à 300° et le sarcelle/cyan/aqua à 180° donne une meilleure accessibilité à la vision des couleurs et la teinte de fond claire pour les lignes modifiées donne un contraste cohérent sur les thèmes clairs et foncés.

If you maintain a command line tool, you might find inspiration to improve its accessibility in #9132.

Prise en charge des modules ECMAScript

Node 13 a un support ESM non signalé, et nous avons commencé à travailler un tout petit peu vers un support natif dans Jest. Jest 25 inclut le support pour les fichiers de configuration jest.config.cjs et jest.config.mjs, mais les tests eux-mêmes ne peuvent pas encore être écrits en utilisant l'ESM sans quelque chose comme Babel ou TypeScript qui le transforme en CJS.

Les API que Jest utilisera sont encore marquées et expérimentales, donc ne vous attendez pas à un support immédiat. L'équipe des modules Node.js travaille activement sur ces API, et nous garderons un œil sur l'évolution de la situation et nous les expérimenterons afin de pouvoir fournir des retours. You can subscribe to this issue to get any updates about the implementation status in Jest.

Autres améliorations et mises à jour

• Jest has passed 1000 unique contributors. C'est une étape incroyable ! Merci à tous ceux qui nous aident à rendre les tests aussi agréables que possible.
• Grâce au membre de la communauté Josh Rosenstein, Jest prend désormais en charge le BigInt dans la plupart des comparateurs, tels que toBeGreaterThan. Jest comprend également les littéraux bigint immédiatement.
• La fonctionnalité de Jest --detect-leaks a été défaillante pour Node 12 et plus récent - ceci a été corrigé dans Jest 25.
• Comme annoncé dans l'article du blog de Jest 24, la base de code de Jest a été réécrite en TypeScript - ce travail a été achevé dans Jest 24.3. Ainsi, si vous utilisez l'une des parties individuelles de Jest, vous devriez bénéficier d'une excellente intégration avec l'IDE. Pour l'avenir, nous voulons vraiment faire en sorte que les simulations de Jest jouent mieux avec les systèmes de type, et nous aimerions que la communauté nous aide à cet égard. Please chime in here with ideas and send PRs! Nous allons également étudier le déplacement des typages pour l'utilisation de Jest en tant qu'exécuteur de tests de DefinitelyTyped vers Jest lui-même.
• Le paquet jest-diff exporte maintenant des fonctions comme diffLinesUnified et diffStringsUnified qui ont des options de configuration, afin que d'autres applications puissent formater les différences d'une manière personnalisée. Pour plus d'informations et d'exemples de code, consultez son nouveau fichier README.md dans le dépôt de Jest ou sur les dépôts de paquets.
• Grâce à un membre de la communauté Wei An Yen, Jest ne mettra plus en évidence les comparateurs asymétriques passants dans les erreurs d'expectation. Il s'agit d'un problème de longue date avec les comparateurs asymétriques et nous sommes très heureux qu'il soit enfin résolu.
• Pour la deuxième année consécutive, Jest a remporté le plus haut prix de satisfaction de State of JS. Nous sommes incroyablement reconnaissants pour le soutien de la communauté et espérons que nous pourrons tirer parti de cet élan pour rendre 2020 encore meilleure !

Plans pour l'avenir

• La configuration de Jest est vaste et quelque peu maladroite - il y a souvent au moins deux façons de faire la même chose, souvent même plus. Pour Jest 26, nous espérons condenser la configuration et la rendre plus prévisible. See this issue for details.
• Nous espérons également être en mesure de fournir une API programmatique appropriée pour l'exécution de Jest, afin de faciliter l'intégration dans les IDE et autres outils. Please see this tracking issue.
• Il y a eu un PR ouvert pour l'ajout de Lolex comme implémentation des temporisateurs fictifs de Jest depuis décembre 2017. Bien que nous ne l'ajoutons pas à une API publique dans Jest 25, son support est techniquement inclus et nous cherchons comment l'exposer pour que les gens puissent le tester et l'expérimenter. L'utiliser signifie que vous pouvez simuler la date et d'autres fonctions de temporisation que Jest ne prend pas en compte actuellement. Notez que cela doit être considéré comme expérimental, et un support API approprié viendra dans une version ultérieure. Follow this PR for the latest updates on the status.

Happy Jesting ! 🃏