Test Driven Development in React

Es ist heutzutage nahezu unmöglich, mit dem Tempo mitzuhalten, in dem neue JavaScript-Frameworks auftauchen. Ich denke, es ist gut, sich auf einige wenige zu konzentrieren. Für mich bedeutet das, sich auf die „großen Drei“ zu konzentrieren, wie in diesem Beitrag definiert – und speziell darauf, grundlegendes TDD (Test Driven Development) mit React zu machen.

Voraussetzungen

Dieser Blogbeitrag setzt voraus, dass Folgendes auf Ihrem Rechner installiert ist:

• NodeJS (LINK)
• Ein beliebiger Quellcode-Editor Ihrer Wahl. Ich verwende Visual Studio Code (LINK)

Ergebnis

Am Ende dieses Beitrags haben Sie Folgendes eingerichtet:

• Eine einfache React-Anwendung mit zwei Komponenten, erstellt mit dem Node-Paket „create-react-app“
• Unit-Tests
  • Smoke Testing
  • Isoliertes (Shallow) Testing
  • Snapshot Testing
  • Integriertes Testing
• Code Coverage

Das resultierende Projekt finden Sie HIER.

Einrichtung einer React-Anwendung

Es gibt ein großartiges GitHub-Repository namens „create-react-app“, das mit npx ausgeführt werden kann. Der große Vorteil von npx ist, dass es das Paket nicht global installiert. Das Paket dient als Gerüstwerkzeug zur Erstellung der React-Anwendung. Wir wollen es nach der Erstellung nicht dauerhaft installiert haben und immer mit der neuesten Version arbeiten. Weitere Funktionen finden Sie unter NPX.
Verwenden Sie dazu folgenden Befehl:

C:Usersusernametemp>npx create-react-app my-app

Die Ordnerstruktur sieht dann folgendermaßen aus:

Die Anwendung enthält einige Standardfunktionen und ist ein guter Ausgangspunkt für einen TDD-Ansatz. Testdateien können die Endung .test oder .spec haben.

Smoke Testing

Öffnen wir App.test.js:
[gist id=c6af883db9045dc062bbbdbba3c0f10e]

Am Anfang wird React als Frontend-JavaScript-Bibliothek benötigt. „ReactDOM“ enthält Methoden für den DOM-Zugriff auf oberster Ebene einer React-Anwendung. Die dritte Import-Anweisung stellt sicher, dass die „App“-Komponente für Tests verfügbar ist.

Der Standard-Smoketest rendert die App-Komponente in einem div-Element und prüft, ob keine Fehler auftreten. Die Methode unmountComponentAtNode entfernt anschließend das div und den gesamten untergeordneten DOM. Diese Methode gibt true zurück, wenn das Unmounting erfolgreich war, und kann daher in eine Expect-Anweisung eingebettet werden:

[gist id=173a189cc01a897be6d983154e7864a9]

ReactDOM sollte nur für Funktionalität, nicht für Tests verwendet werden. Ich habe es hinzugefügt, da das Team von „create react app“ es in der Testdatei verwendet. Allgemein wird jedoch empfohlen, den React Test Renderer oder Enzyme zu verwenden. Die Aussage des Teams dazu finden Sie hier.

Beim Ausführen der Tests (mit dem Befehl „npm test“) wird Folgendes angezeigt:

In Visual Studio Code ist die Jest-Erweiterung von Orta sehr nützlich, da sie anzeigt, welche Tests in den Testdateien fehlgeschlagen sind.

Zum Beispiel (beachten Sie den roten Punkt vor dem Test und den Kommentar nach dem „expect“):

TDD anwenden

Lassen Sie uns einige Unit-Tests für einen einfachen Button erstellen. Dieser Button soll eine React-Komponente sein, deren Titel gesetzt werden kann.

Ich habe die Ordnerstruktur nach dem React Style Guide von github.com/pagarme/react-style-guide erstellt.

Shallow Testing

Aus dem vorherigen Abschnitt wissen wir, wie man einen Smoke-Test mit ReactDOM erstellt. Nun wollen wir Shallow Testing durchführen – also das Testen von Komponenten in Isolation, ohne ihre Kind-Komponenten vollständig zu rendern.

Enzyme ist eine großartige Bibliothek dafür, also installieren wir sie zuerst:
npm install --save-dev enzyme enzyme-adapter-react-16

Wir erstellen eine neue Datei, um den Enzyme React Adapter einzurichten.

[gist id=731965367dadf237f6293c45d3b70882]

In der package.json müssen wir die setupTests.js-Datei einbinden:
[gist id=0f6680c403eba1f8f7f6093c4fc8bbd6]

Der Shallow-Test in Button.test.js ist wie folgt definiert:
[gist id=d3b54b0f7a1c8586559396755e89c2ec]

Enzyme rendert hier eine „Shallow“-Version der Button-Komponente. Wenn der Button weitere untergeordnete Komponenten hätte, würden diese nicht vollständig gerendert. Shallow Tests sind nützlich, um Komponenten isoliert zu prüfen.

Wenn wir npm test ausführen, wird folgender Fehler angezeigt:

Erstellen wir nun die Button-Funktionalität:

[gist id=4a51a1cd7b48b99d11011d5382a7a0fa]

Wenn npm test noch läuft, werden die Tests beim Speichern automatisch erneut ausgeführt und sollten nun erfolgreich sein:

Snapshot Testing

Snapshot-Tests prüfen die Integrität gerenderter Komponenten, indem sie den ausgegebenen HTML-Code überwachen und Warnungen ausgeben, wenn sich dieser ändert. Beim ersten Test wird der Output gespeichert (Snapshot) und als Referenz für zukünftige Änderungen verwendet.
[gist id=642b30126f9fddbc70bc363e40c065e1]

Wenn wir die Tests ausführen, wird ein Snapshot erstellt:

Wenn wir den Text des Buttons von „OK“ zu „Nicht OK“ ändern, passiert Folgendes:

Der neu gerenderte Button stimmt nicht mehr mit dem Snapshot überein, und wir werden darauf hingewiesen.

Integriertes Testing

Beim integrierten Testen wollen wir prüfen, ob Komponenten miteinander kommunizieren können. Zum Beispiel kann ein übergeordneter App-Komponent dem Button einen Text übergeben, der dynamisch angezeigt wird.

[gist id=be3643ad29accb139d3e49e8e7c546e0]

[gist id=95d91ef5709526fcb20700a649b4b40f]

Dadurch kann der Button Text aus Props anzeigen. Die Tests sollten bestehen.
Nun kann die App-Komponente den Button mit dem Text „Press“ einfügen. Wir erwarten, dass der HTML-Code den Button mit dem Text „Press“ enthält.

[gist id=901263574c5094fdb19257beed8350a2]

[gist id=d1f395aab8a484ab5876ca44f82ee4da]

[gist id=f72a6c181894c394e5e943cbd5419e86]

[gist id=4700350cb8cdc1a2a63c4733007f0ba8]

Code Coverage

Den Code-Coverage-Bericht kann man mit folgendem Befehl erzeugen:
npm test -- --coverage

Dies ist ein gutes Beispiel dafür, dass Code Coverage nicht alles aussagt. App und Button werden zu 100 % abgedeckt, aber nur, weil die Render-Funktion ausgeführt wurde – nicht unbedingt, weil alle Pfade getestet wurden.

Ergebnis

Wenn wir die Anwendung ausführen, sieht das Ergebnis wie folgt aus:

ReactDOM, React Test Renderer und Enzyme

Für mich war anfangs unklar, wann man ReactDOM, den React Test Renderer oder Enzyme verwenden sollte.

1. ReactDOM (LINK)
   1. Wird für Funktionalität verwendet, nicht für Tests
   2. Interagiert direkt mit dem DOM, daher ist ein DOM erforderlich
2. React Test Renderer (LINK)
   1. Wird für Unit-Tests verwendet
   2. Unterstützt Shallow-, Snapshot- und Integrations-Tests
3. Enzyme (LINK)
   1. Wird für Unit-Tests verwendet
   2. Unterstützt Shallow-, Snapshot- und Integrations-Tests
   3. Bietet viele Hilfsfunktionen zur DOM-Manipulation
   4. Verwendet den React Test Renderer

Aus einer TDD-mit-React-Perspektive würden React Test Renderer und Shallow Renderer ausreichen. Trotzdem ist es sinnvoll, Enzyme frühzeitig hinzuzufügen, da Projekte in der Regel komplexer werden. Ein fertiges Test-Tool erleichtert die Entwicklung erheblich.

Zusammenfassung

In diesem Blogbeitrag habe ich erklärt, wie man grundlegendes TDD mit React umsetzt. Ich habe verschiedene Testtechniken gezeigt (Shallow-, Snapshot- und Integrationstests) und wie diese zu einer robusteren Anwendung beitragen können. Diese Robustheit ist entscheidend im ständig wachsenden JavaScript-Ökosystem.

Das Projekt finden Sie HIER.
Wenn Sie einen Überblick über das Ökosystem erhalten und Ihren Webentwicklungsfokus verbessern möchten, sehen Sie sich diese großartige Roadmap an.