React v19 - Testing mit Vitest

React v19+ — Testing mit Vitest

0:00 Tests haben einen zwiespältigen Ruf. Alle finden sie richtig, viele schieben sie auf — und im Zweifel fällt der Testfall zuerst dem Termindruck zum Opfer. Dabei ist ein Test im Kern etwas ganz Unspektakuläres: eine Behauptung über das Verhalten Ihrer Software. Grün heißt schlicht, dass sie noch stimmt. Genau darin liegt der Wert — nicht beim Schreiben, sondern ein halbes Jahr später, wenn jemand etwas umbaut.

0:24 Heute schauen wir uns Vitest an, einen Test-Runner, der mit Vite-Projekten so gut zusammenspielt, dass eines der klassischen Argumente gegen Tests wegfällt: der Aufwand fürs Aufsetzen.

Testing mit Vitest

0:36 Der rote Faden führt vom ersten grünen Test bis zur nachgespielten Nutzerinteraktion. Wir beginnen mit dem Aufsetzen — was installiert werden muss und warum das bei Vite erfreulich wenig ist. Danach testen wir Komponenten: rendern, etwas suchen, eine Behauptung aufstellen. Und im dritten Kapitel wird es lebendig, denn dort spielen wir nach, was ein Nutzer tatsächlich tut — klicken, tippen — und prüfen, was die Oberfläche daraufhin zeigt.

1:02 Drei Kapitel, jedes mit einer Übung. Kurz zu Ihnen. Beim Thema Tests reicht die Bandbreite in der Praxis von "gar nicht" über "ein paar Utility-Funktionen" bis zu einer belastbaren Abdeckung — sagen Sie gern ehrlich, wo Sie stehen, das ist keine Prüfungsfrage. Die zweite Frage zielt auf etwas Konkretes: Wer schon einmal von Jest auf Vitest umgestellt hat, kennt die angenehme Überraschung, dass fast alles gleich aussieht.

1:27 Und wer noch mit Jest in einem Vite-Projekt kämpft, kennt die andere Seite. Sagen Sie mir außerdem, was heute konkret sitzen soll.

Vitest — Setup & Grundlagen

1:35 Fangen wir beim Aufsetzen an — traditionell der Punkt, an dem gute Vorsätze scheitern. Genau hier hat sich in den letzten Jahren am meisten getan, und das ist der Grund, warum Vitest so schnell so verbreitet ist. Vitest ist ein Test-Runner, der auf Vite aufsetzt — und das ist mehr als eine technische Randnotiz. Bisher brauchten Sie für Tests praktisch eine zweite Bauumgebung: eigene Konfiguration, eigene Transformationen, eigene Auflösung von Importpfaden.

2:02 Und die musste zur ersten passen, sonst lief der Test anders als die Anwendung. Vitest benutzt einfach dieselbe Konfiguration wie Ihr Projekt. Wie ein Werkstattwagen, der schon das passende Werkzeug für Ihr Auto dabeihat. Dazu kommt eine API, die weitgehend der von Jest entspricht — `describe`, `it`, `expect`. Wer Jest kennt, muss praktisch nichts Neues lernen.

2:25 Der erste Punkt ist der eigentliche Grund für die Beliebtheit: keine zweite Konfiguration, die man synchron halten muss. Wer schon einmal einen Alias-Pfad in Jest nachbauen musste, weiß, wie viel Zeit dabei draufgeht. Die Geschwindigkeit ist der zweite Punkt, und sie ist spürbar — moderne Module und die geteilte Transformation machen den Unterschied.

2:45 Der Watch-Mode ist dabei fast der wichtigste Komfort: Er merkt sich, welche Tests von einer geänderten Datei betroffen sind, und führt nur diese aus. Und die Jest-kompatible API bedeutet, dass Ihr vorhandenes Wissen und die meisten Beispiele im Netz weiter gelten. Fünf Schritte, und Sie sind startklar. Sie installieren den Runner, dazu jsdom und die Testing Library. Was ist jsdom?

3:08 Eine Nachbildung des Browsers in JavaScript — Ihre Tests laufen in Node, und dort gibt es kein Dokument, kein Fenster, keine Elemente. jsdom liefert genau das nach, und deshalb steht in der Konfiguration diese eine Zeile. Danach ein Eintrag in den Skripten, damit Sie mit einem kurzen Befehl starten können. Die Testdateien selbst erkennt Vitest am Namen. Und der Aufruf startet standardmäßig den Watch-Mode, läuft also mit, während Sie weiterarbeiten.

3:38 Der einfachste denkbare Test — und trotzdem sind alle Bestandteile schon da. Außen `describe`, das mehrere Tests zu einer Gruppe bündelt; das ist reine Ordnung, für die Ausgabe und für Sie selbst. Darin `it` mit einer Beschreibung im Klartext — und diese Beschreibung ist wichtiger, als sie aussieht. Sie erscheint bei einem Fehlschlag, und ein guter Satz erspart dann Rätselraten. Und innen die eigentliche Behauptung: Dieser Ausdruck soll diesen Wert haben.

4:05 Mehr ist ein Test nicht. Sie beschreiben eine Erwartung, und das Werkzeug sagt Ihnen, ob sie noch zutrifft — heute und in jedem künftigen Durchlauf. Jetzt bringen Sie das selbst zum Laufen. Das Lernziel ist bewusst bescheiden: Vitest konfigurieren und einen grünen Test sehen. Genau dieser Moment ist die Hürde, alles danach ist Fleißarbeit. Das Erfolgskriterium ist entsprechend eindeutig — der Befehl läuft und meldet den Test als bestanden.

4:32 Für die Erweiterung habe ich eine klare Empfehlung: Lassen Sie einen Test bewusst rot werden. Schauen Sie sich an, wie die Fehlermeldung aussieht, was sie über Erwartung und Ist-Wert verrät. Ein grüner Test sagt Ihnen wenig — erst der rote zeigt, ob Sie ihm trauen können. Diese vier kosten typischerweise die ersten zwanzig Minuten.

4:52 Ohne die jsdom-Einstellung fehlt schlicht der Browser-Ersatz, und jeder Komponententest scheitert mit einer Meldung über ein nicht vorhandenes Dokument. Der zweite Punkt ist eine Umstellungsfalle: Bei Jest sind `describe` und `it` global verfügbar, bei Vitest importieren Sie sie — oder Sie schalten die globale Variante ausdrücklich ein.

5:10 Dateinamen ohne das Testkürzel werden gar nicht erst gefunden, und dann suchen Sie nach einem Fehler, den es nicht gibt. Und zwei parallel konfigurierte Runner sind zuverlässig eine Quelle unerklärlicher Konflikte.

Component Testing

5:23 Rechnen kann man gut testen. Aber Ihre eigentliche Arbeit sind Komponenten, und die haben eine Oberfläche. Wie prüft man die sinnvoll? Die Antwort der Testing Library ist eine Blickumkehr, und die schauen wir uns jetzt an. Beim Komponententest rendern Sie in die simulierte DOM-Umgebung und schauen sich das Ergebnis an. Der springende Punkt ist, wie Sie hineinschauen.

5:45 Die naheliegende Idee wäre, den internen Zustand abzufragen — die Testing Library verweigert das bewusst. Stattdessen suchen Sie so, wie ein Mensch sucht: nach sichtbarem Text oder nach der Rolle eines Elements, also "der Knopf" oder "die Überschrift". Wie ein Restaurantkritiker, der das Essen bewertet und nicht die Küchenorganisation. Das klingt nach einer Einschränkung, ist aber die eigentliche Stärke: Sie testen, was zählt.

6:11 Der Kern steht im ersten und dritten Punkt, und die gehören zusammen. Ein Test, der die Umsetzung prüft, geht kaputt, sobald jemand die Umsetzung ändert — auch wenn sich für den Nutzer nichts ändert. Solche Tests sind schlimmer als keine, denn sie kosten Pflege und liefern falsche Alarme. Prüfen Sie dagegen das sichtbare Ergebnis, überlebt der Test jedes Refactoring, das das Verhalten nicht anfasst.

6:34 Der zweite Punkt ist ein schöner Nebeneffekt: Wer über Rollen sucht, merkt sofort, wenn eine Oberfläche keine barrierefreien Strukturen hat — dann findet nämlich auch der Test nichts. Ihre Tests machen die Zugänglichkeit unauffällig zum Thema. Drei Handgriffe, dann zwei Ratschläge. Sie rendern, Sie suchen, Sie behaupten — das ist das ganze Muster, und es wiederholt sich in jedem Test.

6:58 Punkt vier ist die Rangfolge beim Suchen: Rollen und sichtbarer Text zuerst, eine Test-ID nur, wenn es wirklich nicht anders geht. Eine Test-ID ist ein Haken, den Sie ausschließlich für den Test ins Markup schrauben — er sagt nichts über die Nutzbarkeit aus. Und Punkt fünf ist Disziplin: ein Verhalten je Test. Ein Test, der fünf Dinge prüft, sagt Ihnen im Fehlerfall nur, dass irgendetwas nicht stimmt.

7:23 Hier steht das Muster in Reinform, und es passt in drei Zeilen. Rendern, suchen, prüfen. Interessant ist das Wörtchen `screen` — das ist Ihr Zugang zum gerenderten Ergebnis, gewissermaßen der Bildschirm, auf den Sie schauen. Und die Suche geht nach dem sichtbaren Text, nicht nach einer Klasse oder einem Element-Typ. Genau so würde ein Mensch die Oberfläche lesen.

7:45 Der Matcher am Ende macht das Ganze lesbar — die Zeile sagt fast im Klartext, was sie behauptet. Ändert jemand später das Markup drumherum, bleibt dieser Test grün, solange der Text noch da ist. Und genau das soll er. Jetzt testen Sie selbst eine Komponente. Das Lernziel ist die Verbindung aus Rendern und zugänglicher Abfrage.

8:05 Erfolg heißt: Der Test findet den erwarteten Text oder die erwartete Rolle und ist grün. Probieren Sie ruhig aus, was passiert, wenn Sie den Text in der Komponente leicht ändern — dann sehen Sie, wie genau die Suche hinschaut. Als Erweiterung ergänzen Sie eine zweite Prüfung über eine Rolle. Der Perspektivwechsel dabei ist lehrreich: Sie fragen nicht mehr nach einem Element-Typ, sondern nach der Funktion, die das Element für den Nutzer hat.

8:31 Der erste Punkt ist die Kernsünde und der Grund, warum Testsuiten unbeliebt werden: Prüfen Sie Interna, brechen Ihre Tests bei jedem Umbau. Der zweite ist ein praktisches Detail mit klarer Regel — die `getBy`-Variante wirft einen Fehler, wenn nichts gefunden wird. Das ist gewollt, aber unbrauchbar, wenn Sie belegen wollen, dass etwas gerade *nicht* da ist. Dafür gibt es `queryBy`, das dann schlicht nichts zurückgibt.

8:55 Test-IDs überall zu verteilen ist die bequeme Abkürzung, die Ihnen den Nutzen der zugänglichen Abfragen wieder wegnimmt. Und ohne Aufräumen zwischen den Tests beeinflussen sich Testfälle gegenseitig — der klassische Grund dafür, dass ein Test allein grün ist und in der Suite rot.

Interaktive Component Tests

9:12 Bis hier haben wir nur den Startzustand geprüft. Aber der interessante Teil einer Oberfläche ist, was passiert, wenn jemand etwas tut. Also spielen wir jetzt den Nutzer nach — klicken, tippen — und schauen, ob die Anwendung reagiert wie versprochen. Interaktive Tests simulieren, was ein Mensch tut, und prüfen danach die veränderte Oberfläche.

9:33 Das Werkzeug dafür heißt `user-event`, und der Unterschied zur einfachen Variante lohnt eine Erklärung. Ein Klick ist nämlich nicht ein Ereignis, sondern eine ganze Kette: Der Zeiger bewegt sich über das Element, die Maustaste geht herunter, das Element bekommt den Fokus, die Taste geht hoch, dann erst folgt der Klick. `user-event` spielt diese Kette nach. Die rohe Variante feuert nur das eine Ereignis — und übersieht damit Fehler, die im echten Browser sofort aufgefallen wären.

10:02 Der erste Punkt ist der entscheidende: Der Startzustand ist selten das, wo Fehler sitzen. Probleme entstehen beim zweiten Klick, beim leeren Formular, beim schnellen Hin und Her. Genau das deckt ein interaktiver Test ab. Die realistische Ereigniskette sorgt dafür, dass Ihr Test dem echten Browser nahekommt statt einer Vereinfachung.

10:21 Regressionen in der Interaktionslogik fallen früh auf — und das ist die Sorte Fehler, die man bei manuellen Klicktests zuverlässig übersieht, weil man immer denselben Weg geht. Und `findBy` löst das Problem asynchroner Ergebnisse sauber, ohne dass Sie mit Wartezeiten hantieren müssen. Ein Schritt mehr als vorher. Zuerst richten Sie den simulierten Nutzer ein — diese eine Zeile am Anfang, dann rendern Sie wie gehabt.

10:46 Die Aktion selbst, Klick oder Eingabe, muss abgewartet werden; das `await` ist hier keine Formalität, dazu gleich mehr. Danach prüfen Sie die veränderte Oberfläche, nicht den Zustand im Inneren. Und Punkt fünf ist der, den Sie sich merken sollten: Sobald etwas asynchron passiert — ein Datenabruf, eine Animation —, nehmen Sie die wartende `findBy`-Variante.

11:08 Die schaut wiederholt nach, bis das Element auftaucht oder die Zeit abläuft. Hier sehen Sie den kompletten Ablauf: Nutzer einrichten, rendern, klicken, prüfen. Der Test ist als asynchron gekennzeichnet, und das ist notwendig, weil das Klicken gewartet werden muss. Zwei Dinge lohnen den Blick. Gesucht wird über die Rolle "button" — nicht über einen Text, nicht über eine Klasse. Damit funktioniert der Test auch dann noch, wenn jemand die Beschriftung ändert.

11:36 Und die Prüfung danach schaut auf das, was der Nutzer sieht: die neue Zahl auf dem Bildschirm. Nirgends wird gefragt, was der interne Zähler sagt. Verhalten prüfen, nicht Zustand — das ist der rote Faden des ganzen Moduls. Die letzte Übung führt alles zusammen. Sie simulieren eine Nutzeraktion und belegen die Folge in der Oberfläche.

11:57 Das Erfolgskriterium ist einfach: Der Test klickt oder tippt, weist die erwartete Änderung nach und ist grün. Lassen Sie ihn zwischendurch einmal absichtlich fehlschlagen, indem Sie eine falsche Erwartung formulieren — dann sehen Sie, wie präzise die Meldung ist. Als Erweiterung warten Sie ein asynchrones Ergebnis mit `findBy` ab. Genau dieser Fall begegnet Ihnen später ständig, sobald Daten aus dem Netz ins Spiel kommen.

12:22 Der erste Punkt ist mit Abstand der häufigste: das vergessene `await`. Ohne es läuft Ihre Prüfung los, bevor der Klick überhaupt verarbeitet wurde — der Test schlägt fehl, obwohl der Code stimmt. Oder, noch unangenehmer, er ist mal grün und mal rot. Das ist der klassische flackernde Test, dem irgendwann niemand mehr glaubt.

12:41 Der zweite Punkt ist die Bequemlichkeitsfalle: Die rohe Ereignisvariante ist kürzer, aber weniger realistisch. Ein asynchrones Ergebnis mit der nicht wartenden Variante zu prüfen ist derselbe Zeitfehler in anderem Gewand. Und der letzte Punkt schließt den Kreis zum ganzen Modul — prüfen Sie die sichtbare Wirkung, nicht den internen Zustand.

13:02 Ziehen wir die Linie. Vitest teilt sich die Konfiguration Ihres Projekts, und die eine jsdom-Zeile liefert den Browser-Ersatz, ohne den kein Komponententest läuft. Komponenten prüfen Sie über zugängliche Abfragen — sichtbarer Text, Rollen —, nicht über die Interna; das ist der Unterschied zwischen Tests, die Refactorings überleben, und solchen, die man irgendwann entnervt löscht.

13:24 Interaktionen spielen Sie mit `user-event` nach, und das `await` davor ist Pflicht. Alles Asynchrone warten Sie mit der `findBy`-Variante ab. Vom ersten grünen Test bis zur simulierten Nutzerinteraktion.

Fragen & Weiterarbeiten

13:37 Damit sind wir durch. Alle Beispiele und Tests liegen in der Freigabe — nehmen Sie sich besonders die interaktiven Fälle noch einmal vor, das ist der Teil mit dem größten praktischen Wert. Für alles Weitere: vitest.dev für den Runner und die Konfiguration, testing-library.com für die Abfragen. Dort gibt es auch eine Übersicht, in welcher Reihenfolge Sie Elemente suchen sollten — eine Seite, die sich auszudrucken lohnt.

14:02 Und wenn Sie eines aus diesem Modul mitnehmen, dann bitte den Gedanken dahinter: Testen Sie, was der Nutzer erlebt, nicht wie Sie es gebaut haben. Bei Fragen erreichen Sie uns unter der Adresse auf der Folie. Vielen Dank.