Jest 15.0: Neue Standardeinstellungen für Jest

Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Im vergangenen Jahr haben wir Jest schneller gemacht, die Konfiguration vereinfacht, zahlreiche Funktionen hinzugefügt und Snapshot-Testing eingeführt. Allerdings gab es zwei Bereiche, in die wir wenig investiert haben: die CLI-Ausgabe und das Nutzererlebnis. Mit Jest 15 verändern wir das Framework grundlegend, um es für Anfänger und erfahrene Nutzer gleichermaßen einfacher zu bedienen. Wir freuen uns, dass sich unsere Investition in Jest nun auszahlt: Wir können schnell agieren und das Framework für Facebook und die Open-Source-Community mit hoher Geschwindigkeit verbessern. Jests Ziel ist es, mit umfassenden Funktionen ausgestattet zu sein und so wenig Konfiguration wie nötig zu erfordern. Kürzlich hatten wir Gelegenheit, unser Konzept in einem create-react-app-Issue zu erläutern.

Die wichtigste Änderung betrifft eine Reihe von neuen Standardeinstellungen. Als bestehender Jest-Nutzer müssen Sie Ihre Konfiguration für Jest 15 höchstwahrscheinlich anpassen. In den meisten Fällen wird dies Ihr Setup vereinfachen, und Jest wird während des Upgrades hilfreiche Fehlermeldungen liefern. Alle neuen Standardeinstellungen können deaktiviert werden, um Ihren Bedürfnissen gerecht zu werden. Wir betrachten die deaktivierten Funktionen jedoch weiterhin als entscheidend für Jest in bestimmten Situationen und werden sie bei Facebook langfristig nutzen und unterstützen. Unsere API-Dokumentation wurde ebenfalls vollständig überarbeitet, um diese Änderungen widerzuspiegeln. Dieser Pull Request für React zeigt einige der notwendigen Änderungen für bestehende Projekte.

Neue CLI-Fehlermeldungen und Zusammenfassungen

Im Rahmen unserer Bestrebungen, Jasmine schrittweise aus Jest zu entfernen, wurde der Austausch aller Jasmine-Matcher nahezu abgeschlossen. Wir haben viel Zeit darauf verwendet, jede Fehlermeldung für jeden Matcher zu optimieren, um Nutzern bei Testfehlern – dem Moment, in dem Jest den größten Mehrwert bieten sollte – die besten Hinweise zu liefern. Zusätzlich zur Anzeige der erwarteten und erhaltenen Werte wird für die Matcher toBe und toEqual ein Diff ausgegeben, um Fehler schneller zu erkennen. Wir haben mehr Farben hinzugefügt und relevante Dateien aus Stack Traces deutlicher hervorgehoben.

Hier ein Vorher-Nachher-Vergleich auf einem hellen Terminal: Es funktioniert auch gut mit dunkleren Farben:

Neuer Watch-Befehl

Wir haben jest --watch komplett neu geschrieben, um es interaktiver zu gestalten. Es kann nun durch Drücken von a oder o zwischen dem Ausführen aller Tests oder nur der Testdateien wechseln, die mit geänderten Dateien zusammenhängen. Durch Drücken von p erscheint ein Eingabefeld, um ein Testmuster zur Fokussierung auf bestimmte Dateien festzulegen. Snapshot-Tests können durch Drücken von u aktualisiert werden.

Verbesserungen bei jest-react-native

Mocks für ListView, TextInput, ActivityIndicator, ScrollView und weitere wurden hinzugefügt. Bestehende Mocks wurden aktualisiert, um echte Implementierungen zu verwenden, und bestehende Snapshots müssen beim Upgrade auf Jest 15 wahrscheinlich aktualisiert werden. Eine mockComponent-Funktion wurde zu jest-react-native hinzugefügt, um native Komponenten zu mocken:

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

Es gab außerdem Verbesserungen beim Mocken von Bildern, dem Fetch-Modul und anderen nativen APIs.

Gebufferte Konsolenmeldungen

Jest parallelisiert Testläufe über Worker hinweg, um die Leistung zu maximieren. Bisher leitete Jest Konsolenmeldungen von Workern sofort an den Elternprozess weiter und gab sie aus. Bei parallel ausgeführten Tests war es oft schwer zu erkennen, welcher Test und welches Modul eine Log-Funktion aufrief. In Jest 15 werden alle Konsolenmeldungen gepuffert und zusammen mit einzelnen Testergebnissen ausgegeben. Zusätzlich werden Dateiname und Zeilennummer des Log-Aufrufs angezeigt, sodass der Code leicht überprüft werden kann.

Vergleichen Sie die Ausgabe der vorherigen Jest-Version mit Jest 15:

Automocking deaktiviert

Automocking ist in Jest jetzt standardmäßig deaktiviert. Dies war bei Weitem die verwirrendste Funktion für neue Nutzer und ergibt für kleinere Projekte oft wenig Sinn. Wir haben Automocking bei Facebook eingeführt und es funktionierte hervorragend, als Unit-Tests in einer großen bestehenden Codebase mit wenigen existierenden Tests übernommen wurden. Mit der Zeit zeigte sich jedoch, dass Entwickler mehr Zeit damit verbrachten, gemockte/ungemockte Module zu bekämpfen, als normalerweise für das Schreiben eines Tests nötig gewesen wäre. Wir bemerkten auch, dass Bibliotheksautoren oft eine große Anzahl grundlegender Module benötigen, die ständig manuell ungemockt werden müssen. Selbst bei Jest selbst erkannten wir, dass die Mehrheit der Tests Automocking manuell deaktiviert hatte. Wir sind nach wie vor überzeugt, dass explizites Automocking enorm wertvoll sein kann. Diese Änderung ersetzt lediglich implizite Mocks durch explizite Mocks via Aufrufe von jest.mock(moduleName).

Wenn du Automocking weiterhin standardmäßig nutzen möchtest, aktiviere die automock-Einstellung in deiner Konfiguration oder rufe jest.enableAutomock() manuell in deiner Test- oder Setup-Datei auf.

Testdatei-Muster

Nicht jeder nutzt dieselbe Konvention eines __tests__-Ordners zum Speichern von Tests. Jest 15 sucht nun auch nach Dateien mit den Endungen .spec.js oder .test.js, zwei beliebten Community-Standards. Jest 15 entfernt außerdem die Konfigurationsoptionen testDirectoryName und testFileExtensions und bittet Nutzer, bei Verwendung der alten Optionen auf testRegex umzusteigen.

Persistenz des Modulregisters

Jest setzte früher implizit alle Module vor jedem Test zurück und empfahl, Module in beforeEach oder innerhalb von Tests zu laden. Dies ist nützlich, wenn Module lokale Zustände haben, die nicht zwischen Tests geteilt werden sollten. Allerdings gab es zwei große Veränderungen: ES-Module mit der Top-Level-import-Syntax und ein erneutes Interesse am Schreiben zustandsloser funktionaler Module.

Dies führte zu zahlreichen Inkompatibilitäten. Wir bemerkten auch, dass wir bei Facebook diese implizite Zurücksetzung gar nicht nutzten. Stattdessen verließen wir uns auf explizite Aufrufe von jest.resetModules(), wodurch Entwickler die Kontrolle darüber behalten, wann sie den gesamten Zustand zurücksetzen.

Hier ein Beispiel:

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

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

Der Aufruf von resetModules löscht den Require-Cache. Ein zweiter Aufruf zum Laden desselben Moduls führt zu einer neuen Instanziierung des Moduls und aller seiner Abhängigkeiten. Diese Funktion ist besonders nützlich bei der Arbeit mit Modulen, die Nebenwirkungen haben, wie jest-haste-map.

Wir sind überzeugt, dass es besser ist, Nutzern die Kontrolle zu geben, daher haben wir das implizite Zurücksetzen deaktiviert. Module können mit jest.resetModules() im Code zurückgesetzt werden, und die resetModules-Option kann in der Konfiguration aktiviert werden, um das vorherige Verhalten wiederherzustellen.

Echte vs. simulierte Timer

Standardmäßig mockte Jest früher alle Timer-Funktionen wie setTimeout oder process.nextTick und bot eine API jest.runAllTimers() an, um Timer programmatisch voranzutreiben. Dies ist nützlich, wenn ein Codeabschnitt einen langen Timeout setzt, auf den wir in einem Test nicht warten möchten.

Wir stellten jedoch fest, dass die Anwendungsfälle meist recht isoliert sind. Asynchrone Programmierung ist in unserem Testrunner zudem viel einfacher geworden. Jest verwendet nun standardmäßig echte Timer.

Du kannst dies weiterhin überschreiben, indem du "timers": "fake" in der Konfiguration angibst oder die globalen Schalter jest.useRealTimers() und jest.useFakeTimers() aufrufst.

setupEnvScriptFile vs. setupFiles

Die Konfigurationsoption setupEnvScriptFile war bereits seit einiger Zeit veraltet. Jest 15 entfernt sie komplett und ersetzt sie durch setupFiles. Diese Option erwartet ein Array von Dateipfaden, die nacheinander geladen werden, bevor eine Testdatei ausgeführt wird.

Überarbeitete Code Coverage-Unterstützung

Die Codeabdeckung in Jest kann über jest --coverage genutzt werden und erfordert keine zusätzlichen Pakete oder Konfiguration. Die Unterstützung für Codeabdeckung wurde komplett neu geschrieben, und eine neue Option collectCoverageFrom wurde hinzugefügt, um Codeabdeckungsinformationen von gesamten Projekten zu sammeln – einschließlich nicht getesteter Dateien. Beachten Sie, dass diese Option Glob-Muster verwendet, da wir Konfigurationsoptionen in Zukunft weiter vereinfachen und eine einfachere Alternative zu regulären Ausdrücken bieten möchten. Ein Beispiel finden Sie in Jest's package.json.

Weitere Verbesserungen

Eine große Anzahl weiterer Verbesserungen wurde ebenfalls implementiert:

• Verbesserte Leistung bei kleinen Testläufen.

• Jest verwendet nun den ausführlichen Modus, wenn nur eine einzige Testdatei ausgeführt wird.

• Eine --env-Option wurde hinzugefügt, um die konfigurierte Testumgebung zu überschreiben.

• moduleNameMapper verwendet nun einen Auflösungsalgorithmus.

• Jest funktioniert jetzt mit Pfaden, die Sonderzeichen wie Klammern enthalten.

• global.global wurde zur Node-Umgebung hinzugefügt.

• Behoben: babel-plugin-jest-hoist verursachte einen ungültigen Fehler, wenn eine beliebige Benutzerfunktion mock hieß.

• Die Auflösung von testEnvironment wurde korrigiert, um jest-environment-{name} anstelle von nur {name} zu bevorzugen. Dies verhindert einen Modulkonflikt, wenn jsdom als Testumgebung verwendet wird.

• Verbesserungen an Jest's eigener Testinfrastruktur durch die Zusammenlegung von Integrations- und Unit-Tests. Codeabdeckung wird nun für Jest selbst gesammelt.

Wir blicken zufrieden auf alle Änderungen zurück, die wir mit Hilfe der Community vorgenommen haben, und freuen uns sehr darauf, Jest in den nächsten Monaten noch besser zu machen. Bitte melden Sie ein Issue, wenn etwas nicht wie erwartet funktioniert, und senden Sie uns Pull Requests.

Als nächstes: Concurrent Reporter.