Jest 27: Neue Standardeinstellungen für Jest, 2021 Edition ⏩

Inoffizielle Beta-Übersetzung

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

Im Jest-26-Blogbeitrag vor etwa einem Jahr kündigten wir an, dass Jest 27 nach zwei Hauptversionen mit wenigen Breaking Changes einige Schalter umlegen wird, um bessere Standardeinstellungen für neue oder migrationsfähige Projekte zu setzen. Dies gibt uns die Möglichkeit, einige Pakete aus der Standardverteilung von Jest 28 zu entfernen und sie stattdessen als separat installierbare und anpassbare Module zu veröffentlichen. Alle, die die neuen Standards nutzen, profitieren von einer kleineren Installationsgröße, während Benutzer, die diese Pakete benötigen, sie weiterhin separat installieren können.

Mit der ersten großen Änderung der Standardeinstellungen seit den New Defaults for Jest der bahnbrechenden Version 15 ist Jest 27 nun da, um Jest auch in Zukunft schnell, schlank und relevant zu halten. Wir erklären diese Änderungen der Standardeinstellungen und andere bemerkenswerte Breaking Changes in diesem Beitrag. Aber zuerst schauen wir uns einige spannende neue Funktionen an!

Funktionsupdates

Zunächst kann der interaktive Modus, den ihr vielleicht vom Überprüfen und Aktualisieren fehlgeschlagener Snapshots kennt, jetzt auch verwendet werden, um fehlgeschlagene Tests einzeln durchzugehen. Verdienst hierfür geht an den Erstmitwirkenden @NullDivision, der diese Funktion implementiert hat!

Apropos Snapshots: Eine der aufregenderen Funktionen, die wir in den letzten Jahren ausgeliefert haben, sind Inline Snapshots, die vor fast drei Jahren in einem Minor-Release von Jest 23 eingeführt wurden. Allerdings kamen sie mit der Einschränkung, dass Projekte, die sie nutzen wollen, Prettier zur Codeformatierung verwenden müssen, da Jest dies nutzt, um sicherzustellen, dass die Datei, in die es die Snapshots schreibt, ordnungsgemäß formatiert bleibt.
Und so hatten wir in den meisten dieser Jahre einen Pull Request in der Pipeline, um diese Einschränkung zu beseitigen und Inline Snapshots ohne Prettier zu ermöglichen. Er hat weit über hundert Kommentare angesammelt, ohne die davon abgespaltenen und zuerst umgesetzten PRs zu berücksichtigen, und sogar einmal den Besitzer gewechselt, nachdem er ursprünglich von einem anderen Erstmitwirkenden, @mmkal, unter dem amüsanten Arbeitstitel 'Uglier Inline Snapshots' eingereicht wurde. Mit dem rasanten Aufstieg von Prettier in jüngster Zeit ist diese Verbesserung heute vielleicht weniger nötig als 2018, aber trotzdem kennen wir das Gefühl, in ein Projekt zu kommen, das Prettier nicht verwendet, und plötzlich keine Inline-Snapshots mehr nutzen zu können. Nimmermehr!

Der Hauptgrund, warum die Umsetzung so lange dauerte, war überraschenderweise ein Speicherüberlauf in unserer Build-Pipeline. Es stellte sich heraus, dass die Abhängigkeiten, die wir für jede Testdatei laden, um das Parsing, das Einfügen von Snapshots und das Drucken durchzuführen, einen erheblichen Zeit- und Speichermehraufwand verursachen.
Mit einigen Tricks haben wir die Initialisierung pro Testdatei um etwa 70 % im Vergleich zu Jest 26 beschleunigt. Beachte, dass du diese große Leistungsverbesserung in deinem Projekt fast sicher nicht sehen wirst – um sie optimal zu bemerken, bräuchtest du viele Testdateien, die jeweils sehr schnell laufen, und der Overhead bei Verwendung einer JSDOM-Umgebung übertrifft jede solche Verbesserung bei weitem.

In anderen Neuigkeiten schreitet die native ESM-Unterstützung voran, aber einige große Herausforderungen, etwa beim Mocking, liegen noch vor uns, und wir betrachten die Migration zu ESM weiterhin als enorme Ökosystemanstrengung, bei der Node und viele entscheidende Tools und Pakete sich gegenseitig benötigen, um ein insgesamt überzeugendes Erlebnis zu liefern.
Die ESM-Unterstützung für das Einstecken von Modulen in Jest ist weiter fortgeschritten – benutzerdefinierte Runner, Reporter, Watch-Plugins und viele andere Module können bereits als ES-Module geladen werden.

Wir haben außerdem einen PR zusammengeführt, der den Umgang mit symbolisch verknüpften Testdateien im Testverzeichnis ermöglicht – eine Funktion, die sich Nutzer von Bazel besonders gewünscht haben.

Ein weiterer PR ermöglichte, dass transform-Funktionen asynchron sein können, was Voraussetzung für effektive Transpilierung mit Tools wie esbuild, Snowpack und Vite ist.

Standardeinstellungen ändern sich

Bisher lief bei Verwendung von Jest in der Standardkonfiguration – möglicherweise unbewusst – Code, der vor Jahren vom Testrunner Jasmine 2.0 abgespalten wurde und Test-Framework-Funktionen wie describe, it und beforeEach bereitstellt. 2017 schrieb Aaron Abramov ursprünglich einen Ersatz für den Jasmine-Code namens jest-circus, um Fehlermeldungen, Wartbarkeit und Erweiterbarkeit zu verbessern.
Nach Jahren intensiver Nutzung bei Facebook und in Jest selbst sowie jüngster Einbindung in create-react-app sind wir überzeugt, dass jest-circus hochkompatibel zu jest-jasmine2 ist und in den meisten Umgebungen mit minimalem Migrationsaufwand funktioniert. Geringfügige Unterschiede in Ausführungsreihenfolge oder Striktheit sind möglich, doch wir erwarten keine größeren Probleme außer bei Code, der sich auf Jasmine-spezifische APIs wie jasmine.getEnv() verlässt. Bei starker Abhängigkeit von solchen APIs können Sie den Jasmine-basierten Testrunner durch Konfiguration von "testRunner": "jest-jasmine2" reaktivieren.

Das Ausführen von Tests in einer JSDOM-Umgebung verursacht erhebliche Performance-Einbußen. Da dies bisher Jest-Standard war, wussten viele Nutzer von Node-Apps beispielsweise nicht, dass sie eine aufwändige DOM-Umgebung erhielten, die sie gar nicht benötigen.
Daher ändern wir die Standard-Testumgebung von "jsdom" zu "node". Bei Verwendung von DOM-APIs ohne explizite Konfiguration erhalten Sie nun Fehlermeldungen (z.B. bei Zugriff auf document). Beheben lässt sich dies durch Konfiguration von "testEnvironment": "jsdom" oder Umgebungskonfiguration pro Datei.
Für Projekte mit gemischten Anforderungen empfehlen wir die schnelle "node"-Umgebung als Standard, während DOM-abhängige Tests gezielt per Docblocks gekennzeichnet werden.
Im nächsten Major-Release werden wir jest-jasmine2 und jest-environment-jsdom aus Jest entfernen und separate Installation voraussetzen – viele Nutzer profitieren so von kleineren Installationsgrößen ohne unnötigen Ballast.

Eine weitere geänderte Standardeinstellung betrifft Fake Timers (alias Timer Mocks). In Jest 26 führten wir eine optionale "moderne" Implementierung ein, die über dieselbe API zugänglich ist, aber umfassenderes Mocking (z.B. für Date und queueMicrotask) bietet.
Diese moderne Fake-Timers-Implementierung wird nun Standard. Sollten subtile Implementierungsunterschiede Ihre Migration unverhältnismäßig erschweren, können Sie die alte Version via jest.useFakeTimers("legacy") oder bei globaler Aktivierung durch Konfiguration von "timers": "legacy" nutzen.

Funktionen mit Breaking Changes

Wir führten weitere kleinere Breaking Changes ein, um unbeabsichtigte Fehler durch unerlaubte Aktionen zu verhindern:

• Derselbe done-Test-Callback darf nicht mehrfach aufgerufen werden

• das Aufrufen von done und das Zurückgeben eines Promises dürfen nicht kombiniert werden,

• ein describe-Block darf nichts zurückgeben,

und wir haben einige TypeScript-Typen strenger gemacht.

Module, die in den folgenden Konfigurationsoptionen verwendet werden, werden nun wie der restliche Code transformiert, was zu Problemen führen kann, wenn ihr euch darauf verlassen habt, dass sie unverändert geladen werden:

• testEnvironment

• runner

• testRunner

• snapshotResolver

Weitere Breaking Changes

Wir haben einige lang veraltete Funktionen entfernt:

• jest.addMatchers (verwendet stattdessen expect.extend)

• jest.resetModuleRegistry (verwendet stattdessen jest.resetModules)

• jest.runTimersToTime (verwendet stattdessen jest.advanceTimersByTime)

Viele Pakete von Jest wurden auf ESM-Exporte umgestellt (obwohl sie weiterhin als CommonJS ausgeliefert werden). Wenn ihr z.B. pretty-format direkt verwendet, müsst ihr euren Import möglicherweise auf einen default-Import anpassen.

Wir haben den Support für Node 13 eingestellt - aber Jest unterstützt immer die aktuelle und alle LTS-Versionen von Node. Jest 27 unterstützt weiterhin Node 10, das erst kürzlich aus dem Support genommen wurde.

Wie immer könnt ihr das vollständige Changelog und die Liste der Breaking Changes hier einsehen.

Abschließend möchten wir uns bei der Community bedanken, die Jest im State of JS 2020 erneut eine überragende Zufriedenheitsrate von 96% beschert hat! Bleibt alle gesund, und wir hoffen, dass ihr Jest auch in den kommenden Jahren und Versionen gerne weiterverwendet! 🃏