React-Anwendungen testen: Unit-, Integrations- und E2E-Tests

Kurz gefasst: Eine gute Teststrategie für React-Anwendungen setzt auf drei Ebenen: statische Prüfung mit TypeScript und ESLint, viele Integrationstests auf Komponentenebene mit Vitest und React Testing Library sowie wenige, gezielte End-to-End-Tests mit Playwright für die geschäftskritischen Abläufe. Getestet wird das Verhalten aus Sicht der Nutzer, nicht die interne Umsetzung. So fangen Tests echte Fehler ab und brechen nicht bei jedem Umbau.

Warum Tests in React-Projekten oft scheitern

Viele Teams haben Tests, vertrauen ihnen aber nicht. Entweder brechen sie bei jeder kleinen Änderung am Code, obwohl die Anwendung weiterhin funktioniert, oder sie laufen grün, während im Browser etwas kaputt ist. Beides hat dieselbe Ursache: Die Tests prüfen Implementierungsdetails wie interne State-Werte oder Komponentennamen statt dessen, was Nutzer sehen und tun.

Eine Teststrategie beantwortet deshalb zwei Fragen: Was wollen wir absichern, und auf welcher Ebene geht das am günstigsten?

Die Ebenen einer Teststrategie

Statische Analyse

Die billigsten Fehler sind die, die gar nicht erst in einen Test gelangen. TypeScript findet falsche Props, vergessene Null-Prüfungen und Tippfehler in Feldnamen, bevor der Code läuft. ESLint mit den Regeln für React Hooks deckt typische Fehler bei Abhängigkeiten auf. Beides läuft im Editor und in der CI-Pipeline. Mehr zu sauberem TypeScript-Code lesen Sie in Clean-Code-Prinzipien für TypeScript-Projekte.

Unit-Tests für reine Logik

Funktionen ohne Oberfläche, also Preisberechnungen, Validierungen, Datumslogik oder Formatierungen, testen Sie mit Vitest oder Jest direkt. Diese Tests sind schnell, stabil und eignen sich gut für viele Randfälle. Vitest hat sich in Projekten mit Vite als Build-Werkzeug weitgehend durchgesetzt, weil es dieselbe Konfiguration nutzt.

Integrationstests auf Komponentenebene

Hier liegt der größte Nutzen. Mit React Testing Library rendern Sie eine Komponente oder einen ganzen Bildschirm, interagieren damit wie ein Nutzer und prüfen das Ergebnis. Elemente werden über ihre Rolle und Beschriftung gefunden, etwa „Button mit dem Namen Speichern“, statt über CSS-Klassen. Das hat einen Nebeneffekt: Eine Oberfläche, die sich so gut testen lässt, ist meist auch für Screenreader zugänglich.

API-Aufrufe simulieren Sie mit Mock Service Worker (MSW) auf Netzwerkebene. Die Komponente nutzt dann ihren echten Datenabruf, bekommt aber kontrollierte Antworten, auch Fehler und langsame Antworten.

End-to-End-Tests für kritische Abläufe

E2E-Tests steuern einen echten Browser durch die laufende Anwendung, inklusive Backend. Playwright ist dafür heute die verbreitetste Wahl, Cypress eine Alternative. Diese Tests sind langsamer und aufwendiger in der Pflege, deshalb beschränken Sie sie auf die Abläufe, deren Ausfall richtig weh tut: Login, Checkout, Anlegen eines Auftrags, Zahlungsprozess. Für React Server Components, die auf dem Server rendern, sind E2E-Tests derzeit oft die zuverlässigste Prüfung.

Was Sie testen sollten und was nicht

Priorisieren Sie nach Risiko. Geschäftsregeln, bei denen ein Fehler Geld kostet, Formulare mit Validierung, Berechtigungen und Abläufe, die Kunden täglich nutzen, verdienen gründliche Tests. Reine Darstellungskomponenten ohne Logik brauchen selten eigene Tests, sie werden in den Integrationstests der Bildschirme ohnehin mitgeprüft.

Snapshot-Tests ganzer Komponenten sind verlockend einfach, werden aber oft gedankenlos aktualisiert und fangen dann nichts mehr ab. Für visuelle Änderungen sind Screenshot-Vergleiche im Browser verlässlicher.

Testabdeckung ist ein nützlicher Hinweis auf ungetestete Bereiche, aber kein Qualitätsziel. Eine hohe Zahl erreicht man auch mit Tests, die nichts Sinnvolles prüfen.

Tests in den Entwicklungsalltag einbauen

Tests helfen nur, wenn sie bei jeder Änderung laufen. In der CI-Pipeline laufen statische Prüfung und Komponententests bei jedem Pull Request, E2E-Tests vor jedem Deployment. Wie Sie das aufsetzen, zeigt unser praktischer Leitfaden zu CI/CD-Pipelines.

Instabile Tests, die mal grün und mal rot sind, sollten sofort repariert oder entfernt werden. Sonst gewöhnt sich das Team daran, rote Pipelines zu ignorieren. Fehlende Tests in einer bestehenden Anwendung nachzurüsten ist eine Form, technische Schulden abzubauen, über die wir in Technische Schulden in Start-ups schreiben.

Häufige Fragen (FAQ)

Lohnen sich Tests auch für kleinere Projekte?

Ja, in reduzierter Form. Schon TypeScript, einige Integrationstests für die wichtigsten Formulare und ein E2E-Test für den Hauptablauf verhindern viele peinliche Fehler. Der Aufwand dafür ist gering im Vergleich zu einem Fehler, den Kunden zuerst bemerken.

Jest oder Vitest?

Beide funktionieren gut mit React Testing Library und haben eine sehr ähnliche API. Vitest ist bei Projekten mit Vite die naheliegende Wahl und meist schneller. In bestehenden Projekten mit Jest gibt es selten einen zwingenden Grund für einen Wechsel.

Wie viele End-to-End-Tests brauche ich?

So wenige wie möglich, so viele wie nötig. Ein Satz von Tests, der die zentralen Abläufe Ihrer Anwendung abdeckt, ist oft ausreichend. Jeder weitere E2E-Test kostet Laufzeit und Pflege und sollte einen klaren Grund haben.

Wer schreibt die Tests, Entwickler oder eine separate QA?

In modernen Teams schreiben Entwickler die Tests zusammen mit dem Code, weil sie die Logik am besten kennen. Eine QA-Rolle ergänzt das mit explorativen Tests und Prüfungen aus Nutzersicht. Beides zusammen ergibt die beste Abdeckung.

Fazit

Tests sollen Vertrauen schaffen, dass eine Änderung nichts kaputt macht. Das gelingt, wenn sie Nutzerverhalten prüfen, auf der günstigsten Ebene ansetzen und bei jeder Änderung automatisch laufen. Ein kleiner, verlässlicher Testbestand ist mehr wert als ein großer, dem niemand traut.

Wenn Sie eine React-Anwendung mit solider Testbasis aufbauen oder eine bestehende absichern möchten, sprechen Sie mit uns über Webentwicklung.