Jest 15.0 : Nouvelles valeurs par défaut pour Jest

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 →

Nous avons passé l'année dernière à rendre Jest plus rapide, plus facile à configurer, à ajouter des tonnes de fonctionnalités et à implémenter les tests par snapshot. Cependant, deux domaines ont reçu peu d'attention : le rendu CLI et l'expérience utilisateur. Avec Jest 15, nous transformons radicalement le framework pour le rendre plus accessible aux débutants comme aux utilisateurs expérimentés. Nous sommes ravis de voir notre investissement porter ses fruits : nous pouvons désormais évoluer rapidement et améliorer le framework pour Facebook et la communauté open source à vitesse grand V. L'objectif de Jest est d'être complet et de nécessiter un minimum de configuration. Nous avons récemment exposé notre philosophie dans une issue de create-react-app.

Le changement majeur concerne un ensemble de nouvelles valeurs par défaut. Les utilisateurs existants devront probablement mettre à jour leur configuration pour Jest 15. Dans la plupart des cas, cela simplifiera votre setup et Jest fournira des messages d'erreur utiles durant la migration. Toutes les nouvelles options peuvent être désactivées selon vos besoins, mais nous considérons ces fonctionnalités comme essentielles dans certains contextes et continuerons à les utiliser et maintenir chez Facebook à long terme. Notre documentation API a été entièrement réécrite pour refléter ces changements. Cette pull request pour React illustre certaines modifications nécessaires pour les projets existants.

Nouveaux messages d'erreur et résumés CLI

Dans le cadre de notre démarche pour supprimer progressivement Jasmine de Jest, le remplacement de tous les matchers Jasmine est quasi terminé. Nous avons consacré beaucoup de temps à peaufiner chaque message d'erreur pour chaque matcher, afin de fournir le meilleur signal aux utilisateurs lors des échecs de tests - moment où Jest doit vous apporter le plus de valeur. En plus d'afficher les valeurs attendues et reçues, un diff est désormais imprimé pour les matchers toBe et toEqual afin de repérer les erreurs. Davantage de couleurs ont été ajoutées et les fichiers pertinents dans les stack traces sont mieux mis en évidence.

Voici une comparaison avant/après sur un terminal clair : Cela fonctionne également avec des fonds sombres :

Nouvelle commande watch

Nous avons entièrement repensé jest --watch pour le rendre plus interactif. Il peut désormais basculer entre l'exécution de tous les tests ou seulement des fichiers de test liés aux fichiers modifiés en tapant a ou o. En appuyant sur p, une invite permet de spécifier un motif de test pour cibler un ensemble de fichiers précis. Les tests snapshot peuvent être mis à jour avec la touche u.

Améliorations de jest-react-native

Des mocks pour ListView, TextInput, ActivityIndicator, ScrollView et d'autres composants ont été ajoutés. Les mocks existants ont été mis à jour pour utiliser les implémentations réelles : les snapshots actuels devront probablement être régénérés lors de la migration vers Jest 15. Une fonction mockComponent a été ajoutée à jest-react-native pour simuler des composants natifs :

jest.mock('MyNativeComponent', () => {
  const jestReactNative = require('jest-react-native');
  return jestReactNative.mockComponent('MyNativeComponent');
});

Des améliorations ont également été apportées pour la simulation d'images, du module fetch et d'autres API natives.

Messages console mis en mémoire tampon

Jest parallélise l'exécution des tests entre différents workers pour maximiser les performances. Auparavant, les messages console des workers étaient transmis au processus parent et imprimés immédiatement. Lors de l'exécution parallèle de plusieurs tests, il était souvent difficile d'identifier quel test ou quel module appelait une fonction de log. Dans Jest 15, tous les messages console sont mis en mémoire tampon et imprimés avec les résultats individuels des tests. Le fichier et le numéro de ligne de l'appel de log sont également indiqués pour faciliter l'inspection du code.

Comparez le rendu des versions précédentes de Jest et de Jest 15 :

Désactivation de l'auto-mock

L'auto-mock est désormais désactivé par défaut dans Jest. C'était de loin la fonctionnalité la plus déroutante pour les nouveaux utilisateurs, et elle n'est souvent pas pertinente pour les petits projets. Nous avions introduit l'auto-mock chez Facebook où il fonctionnait très bien pour l'adoption des tests unitaires dans une base de code existante importante avec peu de tests. Mais avec le temps, nous avons constaté que les développeurs passaient plus de temps à lutter avec les modules mockés/démockés qu'à écrire des tests normalement. Nous avons aussi remarqué que les auteurs de bibliothèques doivent souvent démocker manuellement un grand nombre de modules basiques. Même pour Jest lui-même, la majorité des tests désactivaient manuellement l'auto-mock. Nous restons convaincus que l'auto-mock explicite reste très utile. Ce changement remplace simplement les mocks implicites par des mocks explicites via jest.mock(moduleName).

Si vous souhaitez continuer à utiliser l'auto-mock par défaut, activez l'option automock dans votre configuration ou appelez manuellement jest.enableAutomock() dans votre fichier de test ou de setup.

Conventions de nommage des fichiers de test

Tout le monde n'utilise pas la convention du dossier __tests__ pour stocker les tests. Jest 15 recherche aussi les fichiers se terminant par .spec.js ou .test.js, deux standards populaires dans la communauté. Jest 15 supprime également les options testDirectoryName et testFileExtensions, et demande aux utilisateurs de passer à l'option testRegex si ces anciennes configurations étaient utilisées.

Persistance du registre des modules

Jest réinitialisait implicitement tous les modules avant chaque test et recommandait d'importer les modules dans beforeEach ou directement dans les tests. C'est utile quand les modules ont un état local qui ne devrait pas être partagé entre les tests. Cependant, deux changements majeurs sont intervenus : les modules ES avec la syntaxe import au niveau racine, et un regain d'intérêt pour l'écriture de modules fonctionnels sans état.

Cela a causé de nombreuses incompatibilités. Nous avons aussi constaté qu'à Facebook, nous n'utilisions même pas cette réinitialisation implicite. À la place, nous comptions sur des appels explicites à jest.resetModules(), qui donne aux ingénieurs le contrôle du moment où effacer tout l'état.

Voici un exemple :

const React1 = require('react');
jest.resetModules();
const React2 = require('react');

React1 !== React2; // These two are separate copies of React.

L'appel à resetModules vide le cache require. Un deuxième appel pour importer le même module entraînera une nouvelle instanciation du module et de toutes ses dépendances. Cette fonctionnalité est particulièrement utile pour gérer les modules avec effets de bord, comme jest-haste-map.

Nous pensons qu'il est préférable de laisser le contrôle aux utilisateurs, donc nous avons désactivé la réinitialisation implicite. Les modules peuvent être réinitialisés avec jest.resetModules() dans le code, et l'option resetModules peut être activée dans la configuration pour rétablir le comportement précédent.

Chronomètres réels vs simulés

Par défaut, Jest simulait toutes les fonctions de temporisation comme setTimeout ou process.nextTick et fournissait une API jest.runAllTimers() pour avancer les temporisations programmatiquement. C'est utile quand un code définit un long timeout qu'on ne veut pas attendre dans un test.

Cependant, nous avons constaté que la plupart du temps ces cas d'usage sont assez isolés. La programmation asynchrone est aussi devenue beaucoup plus simple dans notre runner de tests. Jest utilise désormais les chronomètres réels par défaut.

Vous pouvez toujours outrepasser ce comportement en spécifiant "timers": "fake" dans la configuration ou en utilisant les commutateurs globaux jest.useRealTimers() et jest.useFakeTimers().

setupEnvScriptFile vs setupFiles

L'option de configuration setupEnvScriptFile était dépréciée depuis un moment. Jest 15 la supprime complètement et la remplace par setupFiles. Cette option attend un tableau de chemins de fichiers qui sont chargés dans l'ordre avant l'exécution d'un fichier de test.

Prise en charge réécrite de la couverture de code

La couverture de code dans Jest est accessible via jest --coverage sans paquets supplémentaires ni configuration. Le support de la couverture a été entièrement réécrit et une nouvelle option collectCoverageFrom a été ajoutée pour collecter les informations de couverture sur des projets entiers, y compris les fichiers non testés. Notez que cette option utilise des globs car nous souhaitons simplifier davantage les options de configuration à l'avenir et fournir une alternative plus simple aux expressions régulières. Voir le package.json de Jest pour un exemple.

Autres améliorations

Un grand nombre d'autres améliorations ont également été apportées :

• Amélioration des performances pour les petits ensembles de tests.

• Jest utilise désormais le mode verbeux lorsqu'un seul fichier de test est exécuté.

• Ajout d'une option --env pour remplacer l'environnement de test configuré.

• moduleNameMapper utilise désormais un algorithme de résolution.

• Jest fonctionne désormais avec les chemins contenant des caractères spéciaux comme des parenthèses.

• Ajout de global.global à l'environnement Node.

• Correction de l'erreur invalide de babel-plugin-jest-hoist lorsqu'une fonction utilisateur était nommée mock.

• Correction de la résolution de testEnvironment pour privilégier jest-environment-{name} plutôt que {name} uniquement. Cela évite les collisions de modules lors de l'utilisation de jsdom comme environnement de test.

• Améliorations de l'infrastructure de test de Jest en fusionnant tests d'intégration et unitaires. La couverture de code est désormais collectée pour Jest.

Nous sommes ravis de constater tous les changements réalisés avec l'aide de la communauté et sommes impatients d'améliorer encore Jest dans les prochains mois. Merci de créer une issue si quelque chose ne fonctionne pas comme prévu et de nous envoyer vos pull requests.

Prochaine étape : Concurrent Reporter.