Test-Umgebungen

In diesem Dokument werden die Faktoren beschrieben, die sich auf Deine Umgebung auswirken können, sowie Empfehlungen für einige Szenarien.

Testrunner

Mit Testrunnern wie Jest, mocha, ava kannst Du Testsuiten als normales JavaScript schreiben und sie als Teil Deines Entwicklungsprozesses ausführen. Darüber hinaus werden im Rahmen der kontinuierlichen Integration Testsuiten ausgeführt.

• Jest ist weitgehend kompatibel mit React-Projekten und unterstützt Funktionen wie simulierte Module und Timer sowie jsdom-Unterstützung. Wenn Du Create React App verwendest, ist Jest bereits mit nützlichen Standardeinstellungen enthalten.
• Bibliotheken wie mocha funktionieren gut in echten Browserumgebungen und könnten bei Tests helfen, die sie ausdrücklich benötigen.
• Ende-zu-Ende-Tests werden zum Testen längerer Abläufe über mehrere Seiten verwendet und erfordern eine andere Einrichtung.

Simulieren einer Rendering-Oberfläche

Tests werden häufig in einer Umgebung ohne Zugriff auf eine echte Rendering-Oberfläche wie einen Browser ausgeführt. Für diese Umgebungen empfehlen wir, einen Browser mit jsdom zu simulieren, einer einfachen Browserimplementierung, die in Node.js ausgeführt wird.

In den meisten Fällen verhält sich jsdom wie ein normaler Browser, verfügt jedoch nicht über Funktionen wie Layout und Navigation. Dies ist für die meisten webbasierten Komponententests immer noch nützlich, da es schneller ausgeführt wird, als für jeden Test einen Browser starten zu müssen. Es wird auch im selben Prozess wie Deine Tests ausgeführt, sodass Du Code schreiben kannst, um das gerenderte DOM zu untersuchen und zu bestätigen.

Genau wie in einem echten Browser können wir mit jsdom Benutzerinteraktionen modellieren. Tests können Ereignisse auf DOM-Knoten senden und dann die Nebeneffekte dieser Aktionen beobachten und bestätigen (Beispiel).

Ein großer Teil der UI-Tests kann mit dem obigen Setup geschrieben werden: Verwendung von Jest als Test-Runner, gerendert in jsdom, mit Benutzerinteraktionen, die als Sequenzen von Browser-Ereignissen angegeben sind, unterstützt durch den act()-Helfer (Beispiel). Beispielsweise werden viele eigene Tests von React mit dieser Kombination geschrieben.

Wenn Du eine Bibliothek schreibst, die hauptsächlich browserspezifisches Verhalten testet und natives Browserverhalten wie Layout oder echte Eingaben erfordert, kannst Du ein Framework wie Mocha verwenden.

In einer Umgebung, in der Du kein DOM simulieren kannst (z. B. beim Testen von React Native-Komponenten von Node.js), kannst Du Ereignissimulationshelfer verwenden, um Interaktionen mit Elementen zu simulieren. Alternativ kannst Du den fireEvent-Helfer von @testing-library/react-native verwenden.

Frameworks wie Cypress, puppeteer und webdriver sind nützlich, um Ende-zu-Ende-Tests auszuführen.

Simulieren von Funktionen

Beim Schreiben von Tests möchten wir die Teile unseres Codes simulieren, die keine Entsprechungen in unserer Testumgebung haben (z. B. Überprüfung des navigator.onLine-Status in Node.js). Tests könnten auch einige Funktionen ausspionieren und beobachten, wie andere Teile des Tests mit ihnen interagieren. Dann ist es sinnvoll, diese Funktionen gezielt mit testfreundlichen Versionen nachahmen zu können.

Dies ist besonders nützlich für das Abrufen von Daten. Es ist in der Regel vorzuziehen, “gefälschte” Daten für Tests zu verwenden, um die Langsamkeit und Schwankungen aufgrund des Abrufs von echten API-Endpunkten zu vermeiden (Beispiel). Dies trägt dazu bei, die Tests vorhersehbar zu machen. Bibliotheken wie Jest und sinon unterstützen unter anderem Mock-Funktionen. Für Ende-zu-Ende-Tests kann das Simulieren von Netzwerkzugriffen schwieriger sein, aber Du möchtest vielleicht auch die echten API-Endpunkte dabei testen.

Simulieren von Modulen

Einige Komponenten haben Abhängigkeiten von Modulen, die in Testumgebungen möglicherweise nicht gut funktionieren oder für unsere Tests nicht wesentlich sind. Es kann sinnvoll sein, diese Module gezielt mit passendem Ersatz zu simulieren (Beispiel).

Auf Node.js unterstützen Runner wie Jest Simulationen. Du kannst auch Bibliotheken wie mock-require verwenden.

Timer simulieren

Komponenten verwenden möglicherweise zeitbasierte Funktionen wie setTimeout, setInterval oder Date.now. In Testumgebungen kann es hilfreich sein, Zeitfunktionen zu simulieren, um andere Zeitstempel testen zu können. Dies ist großartig, um sicherzustellen, dass Deine Tests schnell ablaufen! Tests, die von Timern abhängig sind, würden immer noch der Reihe nach durchgeführt, aber schneller (Beispiel). Die meisten Frameworks, darunter Jest, sinon und lolex, ermöglichen es Dir, Timer in Deinen Tests zu simulieren.

Manchmal möchtest Du Timer vielleicht nicht simulieren. Vielleicht testest Du beispielsweise eine Animation oder interagierst mit einem Endpunkt, der zeitempfindlich ist (wie ein API-Ratenbegrenzer). Bibliotheken mit Timer-Mocks ermöglichen es Dir, sie pro Test/Suite zu aktivieren und zu deaktivieren, sodass Du explizit auswählen kannst, wie diese Tests ausgeführt werden.

Ende-zu-Ende-Tests

Ende-zu-Ende-Tests sind nützlich, um längere Workflows zu testen, insbesondere wenn sie für Dein Unternehmen von entscheidender Bedeutung sind (z.B. Zahlungen oder Anmeldungen). Für diese Tests möchtest Du wahrscheinlich testen, wie ein echter Browser die gesamte App rendert, Daten von den echten API-Endpunkten abruft, Sitzungen und Cookies verwendet und zwischen verschiedenen Links navigiert. Möglicherweise möchtest Du auch Aussagen nicht nur zum DOM-Status, sondern auch zu den Sicherungsdaten machen (z.B. um zu überprüfen, ob die Aktualisierungen in der Datenbank gespeichert wurden).

In diesem Szenario würdest Du ein Framework wie Cypress, Playwright oder eine Bibliothek wie Puppeteer verwenden, damit Du zwischen mehreren Routen navigieren kannst und Nebeneffekte nicht nur im Browser, sondern möglicherweise auch im Backend finden kannst.