Testen mit Vitest und Playwright

Testen mit Vitest und Playwright

0:00 Testen ist das Modul, das in Seminaren gern gekürzt wird, wenn die Zeit knapp wird. Ich möchte es Ihnen anders verkaufen: Nach dem letzten Modul über Berechtigungen ist es die logische Fortsetzung. Denn was nützt eine sorgfältig gebaute Prüfung, wenn sie beim nächsten Umbau still verschwindet? Wir sehen uns zwei Werkzeuge an, klären, was auf welcher Ebene geprüft wird, und stoßen auf eine Einschränkung, die Next.js-typisch ist.

0:25 Und Sie werden merken: Der Zugriffs-Layer aus Modul neun zahlt sich hier ein zweites Mal aus — diesmal als Teststrategie.

Was auf welcher Ebene geprüft wird

0:33 Beginnen wir mit der Einordnung, denn sie spart Ihnen später eine Diskussion, die in jedem Team einmal geführt wird. Die Next.js-Dokumentation nennt vier Werkzeuge, wir wählen zwei — und wichtiger als diese Wahl ist die Frage, was Sie überhaupt auf welcher Ebene prüfen. Wer das vorher klärt, baut eine Testsuite, die man behält. Wer es nicht klärt, baut eine, die man irgendwann abschaltet.

0:57 Wir nehmen zwei: Vitest prüft Einheiten und Client-Komponenten, schnell und in Millisekunden. Playwright prüft die laufende Anwendung in einem echten Browser, langsam und dafür realistisch. Dazwischen liegt ein Bereich, für den beide ungeeignet wären — und genau den decken wir über den Zugriffs-Layer ab. Das ist keine Notlösung, sondern eine Konsequenz aus unserer Architektur: Weil die Regeln dort und nicht in den Komponenten stehen, lassen sie sich als gewöhnliche Funktionen prüfen.

1:25 Vier Zeilen, und die Fußnote nennt die Lücke: Asynchrone Server-Komponenten fehlen bewusst. Warum, sehen wir in Kapitel drei — es ist eine echte Einschränkung, kein Versäumnis. Sehen Sie sich die vierte Zeile an, die ist mir besonders wichtig: Rollen werden positiv und negativ geprüft. Nicht nur, dass die Verwaltung die Rechnungen sieht, sondern auch, dass der Gast sie nicht sieht.

1:48 Der zweite Test ist der wertvollere, und er wird in neun von zehn Projekten vergessen. Der erste Punkt ist der praktischste: Was langsam ist, wird umgangen. Nicht aus Nachlässigkeit, sondern weil niemand zwanzig Minuten auf eine Rückmeldung wartet — man merged eben doch und schaut später. Der zweite Punkt ist der diagnostische: Ein End-to-End-Test meldet, dass etwas kaputt ist, selten wo.

2:13 Sie bekommen einen roten Balken und eine Seite, die anders aussieht als erwartet. Ein Einheitentest sagt Ihnen: Diese Regel greift nicht mehr. Der Unterschied ist eine Stunde Fehlersuche. Beide Ebenen zusammen ergeben ein Bild, das keine allein liefert. Die ersten beiden Punkte beschreiben zwei entgegengesetzte Fehlformen. Eine Testpyramide ohne Grundlage ist ein Testeimer — oben viel, unten nichts, und jeder Lauf dauert ewig.

2:39 Das andere Extrem ist genauso schlecht: Wer nur Einheiten prüft, merkt nie, dass die Anmeldung kaputt ist, weil die einzelnen Teile ja alle funktionieren. Es ist wie bei einem Auto, bei dem jede Schraube geprüft wurde und niemand losgefahren ist. Sie brauchen beides, und Sie brauchen eine bewusste Aufteilung.

Vitest einrichten

2:58 Jetzt die praktische Einrichtung. Das geht schnell — vier Pakete und eine Konfigurationsdatei. Ein Detail ist dabei wichtig, das man leicht übersieht und das Sie sonst eine halbe Stunde kostet. Es hängt mit einer Entscheidung zusammen, die Sie in Modul eins getroffen haben. Sie brauchen Vitest selbst, eine Browserumgebung, die React-Testbibliothek und ein Zusatzteil für die Pfad-Aliase.

3:22 Danach können Sie Client-Komponenten rendern, Interaktionen auslösen und Ergebnisse prüfen — alles ohne echten Browser, in Millisekunden. Der Weg ist so aus der Dokumentation übernommen; ich habe ihn nur zusammengefasst. Interessant ist weniger die Einrichtung als das, was danach geht und was nicht. Dazu kommen wir gleich.

3:42 Sechs Zeilen, und die dritte ist die, an der es sonst scheitert. Das Zusatzteil für die Pfad-Aliase sorgt dafür, dass Ihre Importe im Test genauso auflösen wie in der Anwendung. Ohne es laufen genau die Kurzschreibweisen ins Leere, die Sie in Modul eins eingerichtet haben — und die Fehlermeldung sagt nur, dass ein Modul nicht gefunden wurde.

4:02 Worauf es ankommt: Das ist eine der Stellen, an denen eine frühe Entscheidung später eine Zeile Konfiguration nach sich zieht. Kennt man den Zusammenhang, ist es in einer Minute erledigt. Ein bewusst einfacher Test, aber sehen Sie sich die Abfrage an: Sie sucht über die Rolle des Elements, nicht über eine CSS-Klasse. Das ist mehr als Geschmackssache.

4:23 Ein Test, der über Rollen sucht, prüft nebenbei mit, ob Ihre Oberfläche für Hilfstechnologien überhaupt lesbar ist. Und er überlebt eine Umgestaltung, bei der sich Klassennamen ändern. Worauf es ankommt: Schreiben Sie Tests so, wie ein Nutzer die Seite wahrnimmt — über Beschriftungen und Rollen, nicht über die interne Struktur.

4:43 Der erste Punkt ist praktisch und trifft jeden beim ersten Pipeline-Lauf: Vitest läuft standardmäßig im Beobachtungsmodus und wartet auf Änderungen. In der Pipeline führt das zu einem Lauf, der nie fertig wird. Der dritte Punkt ist der inhaltlich wichtigste: Ein Test, der nur prüft, dass etwas rendert, sichert wenig ab.

5:02 Er wird grün, solange die Komponente überhaupt existiert. Solche Tests geben ein gutes Gefühl und finden nichts — und sie kosten trotzdem Laufzeit bei jedem Merge.

Server Components und Aktionen prüfen

5:12 Jetzt die Einschränkung, die ich angekündigt habe. Sie ist real, sie steht so in der Dokumentation, und sie hat eine elegante Antwort — die allerdings voraussetzt, dass Sie Ihre Architektur passend geschnitten haben. Genau das haben wir in Modul neun getan, damals aus anderen Gründen. Asynchrone Server-Komponenten lassen sich mit Vitest derzeit nicht sinnvoll rendern — die Dokumentation sagt das ausdrücklich und verweist auf End-to-End- Tests.

5:39 Das ist zunächst unbefriedigend, denn es betrifft einen großen Teil Ihrer Anwendung. Der praktikable Weg besteht darin, das Problem zu umgehen: Trennen Sie Logik vom Rendern. Was in einer Funktion steckt, lässt sich prüfen. Was in einer asynchronen Komponente steckt, nicht. Also gehört die Logik in eine Funktion. Und hier zahlt sich Modul neun ein zweites Mal aus.

6:02 Der Zugriffs-Layer enthält genau die Regeln, die tatsächlich Schaden anrichten können — Rollenprüfung, Besitzprüfung, Zuschnitt der Rückgabe. Und er ist eine gewöhnliche Funktion, ohne React, ohne Rendern, ohne Browser. Sie können ihn mit drei Zeilen je Fall prüfen, in Millisekunden. Was bleibt, ist die Darstellung — und die gehört ohnehin in den Durchstich.

6:24 Ich finde das bemerkenswert: Eine Entscheidung, die wir aus Sicherheitsgründen getroffen haben, löst nebenbei ein Testproblem. Sehen Sie sich an, was hier geprüft wird: der negative Fall. Nicht, dass der eigene Gast seine Buchung sieht — das prüfen alle. Sondern dass ein fremder es nicht kann. Worauf es ankommt: Genau dieser Test schlägt fehl, wenn jemand beim Umbau die Besitzprüfung entfernt, weil sie im Weg schien. Und das ist der Fall, den Sie abfangen wollen.

6:53 Drei Zeilen, und sie bewachen die Regel, an der in Modul elf das halbe Kapitel hing. Der erste Punkt ist eine begriffliche Klärung, die den Einstieg erleichtert: Eine Aktion zu testen heißt, sie als gewöhnliche Funktion aufzurufen. Sie brauchen kein Formular, keinen Browser, kein Absenden. Der dritte Punkt ist einer, der gerade in einem Buchungssystem zuschlägt: Zeitabhängige Logik braucht eine steuerbare Uhr.

7:17 Ein Test, der prüft, ob eine Buchung in der Vergangenheit abgelehnt wird, funktioniert heute und schlägt in drei Monaten fehl — oder, schlimmer, er wird grün, ohne noch etwas zu prüfen.

Playwright einrichten

7:29 Jetzt die andere Ebene: die laufende Anwendung in einem echten Browser. Das ist der Test, der am meisten Vertrauen gibt und am meisten Pflege braucht. Die halbe Arbeit steckt dabei nicht im Test selbst, sondern in zwei Vorbereitungen, die man gern unterschätzt. Sehen wir sie uns an, bevor wir die erste Zeile schreiben. Playwright startet Ihre gebaute Anwendung und steuert einen echten Browser — mit allem, was dazugehört: echtes Rendern, echtes Netzwerk, echte Klicks.

7:56 Für verlässliche Tests brauchen Sie zwei Dinge, die nicht im Test stehen: einen definierten Datenstand und einen Weg, angemeldet zu starten. Ohne das erste hängt jeder Lauf vom vorherigen ab. Ohne das zweite füllt jeder Test erst einmal das Anmeldeformular aus — und Sie prüfen bei jedem Testfall dieselben zehn Sekunden mit.

8:16 Der rote Faden dieser fünf Schritte ist Reproduzierbarkeit. Schritt eins und zwei schaffen die Voraussetzung, Schritt drei spart die Zeit. Schritt vier ist der, den ich betonen möchte und der oft übersehen wird: Testen Sie gegen die gebaute Anwendung, nicht gegen den Entwicklungsmodus. Der Grund kommt aus Modul drei — im Entwicklungsmodus ist das Vorabladen abgeschaltet, das Verhalten ist also ein anderes.

8:39 Und Schritt fünf ist die Regel gegen flatterhafte Tests: auf sichtbare Inhalte warten, nie auf feste Zeiten. Das ist der Weg, den ein Gast tatsächlich geht: Liste öffnen, Liegeplatz wählen, buchen, Bestätigung sehen. Genau ein Test, und er deckt mehr ab als zwanzig Einheitentests — Routing, Datenzugriff, Formular, Aktion, Cache- Invalidierung, Darstellung.

9:02 Worauf es ankommt: Solche Durchstiche sollten Sie sparsam einsetzen und sorgfältig auswählen. Zwei bis drei je Anwendung, die die wichtigsten Geschäftsvorgänge abdecken. Nicht zwanzig, die jede Variante durchspielen — dafür sind sie zu langsam und zu empfindlich. Der erste Punkt ist die häufigste Ursache für unzuverlässige Tests: feste Wartezeiten.

9:24 Sie machen den Lauf langsam und trotzdem unzuverlässig, weil die Wartezeit auf einem ausgelasteten Rechner eben doch nicht reicht. Der dritte Punkt ist die Wiederholung von eben, und ich meine sie ernst: Tests im Entwicklungsmodus prüfen ein anderes Verhalten als die Produktion. Bei Next.js ist dieser Unterschied größer, als man von anderen Frameworks gewohnt ist — Rendering-Modus, Prefetching und Caching verhalten sich anders.

Berechtigungen im Test absichern

9:49 Jetzt zu der Testkategorie, die ich für die wertvollste in einer solchen Anwendung halte. Es geht um Rollen — und darum, dass hier ein Fehler nicht teuer, sondern sehr teuer ist. Gleichzeitig sind diese Tests bemerkenswert stabil, weil sie eine fachliche Zusage beschreiben und keine Implementierung. Rollen sind der Bereich, in dem Tests am meisten wert sind, weil ein Fehler dort kein Anzeigeproblem ist, sondern ein Datenschutzvorfall.

10:15 Wir prüfen deshalb in beide Richtungen: Die Verwaltung sieht die Rechnungsübersicht, und der Gast bekommt an derselben Adresse eine Absage. Beide Tests zusammen beschreiben die Regel vollständig. Einer allein beschreibt sie nur zur Hälfte — und es ist immer dieselbe Hälfte, die fehlt. Zwei Tests, und die Fußnote sagt, welcher zählt: der zweite. Er prüft, dass eine Absage kommt, und zwar die richtige.

10:39 Wenn jemand beim Umbau die Rollenprüfung entfernt, wird dieser Test rot — und nur dieser. Der erste bliebe grün, weil die Verwaltung ja weiterhin alles sieht. Worauf es ankommt: Prüfen Sie nicht nur den Statuscode, sondern denken Sie an die Unterscheidung aus Modul drei. Eine Vierhundertvier statt einer Vierhundertdrei wäre ein anderes Verhalten, auch wenn in beiden Fällen nichts angezeigt wird.

11:03 Der erste Punkt ist der Grund für ihre Langlebigkeit: Sie beschreiben eine fachliche Zusage, keine Implementierung. Dass ein Gast keine fremden Rechnungen sieht, gilt unabhängig davon, wie Ihre Oberfläche aussieht. Sie können die halbe Anwendung umbauen, und diese Tests bleiben gültig. Der dritte Punkt ist ein angenehmer Nebeneffekt: Sie dokumentieren das Rollenmodell ausführbar.

11:25 Wenn jemand neu ins Team kommt und wissen will, wer was darf, sind diese Tests eine bessere Antwort als jedes Dokument — sie können nämlich nicht veralten.

Sofortige Navigationen absichern

11:35 Jetzt eine Neuerung aus Version 16.3, die eine Lücke schließt, über die wir schon in Modul drei gesprochen haben. Es geht darum, ein Geschwindigkeitsversprechen prüfbar zu machen. Das klingt ungewöhnlich — Geschwindigkeit testet man sonst mit Messwerten und Schwellwerten. Hier geht es um etwas anderes: um sichtbare Inhalte.

11:55 Mit einem Testhelfer aus dem Playwright-Paket von Next.js prüfen Sie, welche Inhalte während einer Navigation ohne Netzwerkwartezeit sichtbar sind. Sie schreiben also auf, was der Nutzer in dem Moment sehen soll, in dem er klickt. Der Test schlägt fehl, sobald ein Umbau diese sofortige Oberfläche verändert — ganz gleich, wodurch. Das ist der Kniff: Sie prüfen nicht, wie schnell etwas ist, sondern was da ist.

12:20 Und das ist stabil messbar, im Gegensatz zu Zeiten. Was innerhalb des Blocks steht, muss ohne Warten auf das Netz sichtbar sein — hier also der Liegeplatztitel nach dem Klick. Worauf es ankommt: Sie schreiben damit eine Zusage fest, die sonst nirgends steht. In keiner Dokumentation, in keinem Ticket. Sie lebt bisher nur in der Struktur Ihres Codes, und die kann sich bei jedem Umbau ändern. Dieser Test macht daraus etwas, das man verletzen kann und das dann auffällt.

12:49 Die ersten beiden Punkte beschreiben zwei ganz unspektakuläre Umbauten mit derselben Folge. Jemand baut eine Komponente in den gemeinsamen Kopfbereich, die Cookies liest — die Route ist nicht mehr sofort. Jemand verschiebt eine Suspense-Grenze beim Aufräumen — ein Teil blockiert wieder. Und der dritte Punkt ist der entscheidende: Beides schlägt sonst nirgends fehl.

13:10 Die Seite funktioniert ja. Es fühlt sich nur zäh an, und irgendwann sagt jemand, die Anwendung sei langsam geworden, und niemand weiß seit wann.

Tests im Ablauf verankern

13:19 Zum Abschluss die organisatorische Frage, ohne die alles andere folgenlos bleibt. Tests entfalten ihre Wirkung nicht dadurch, dass sie existieren, sondern dadurch, dass sie im richtigen Moment jemanden aufhalten. Dazu gehört auch eine ehrliche Frage nach der Laufzeit, die viele Teams sich nicht stellen. Tests, die nur lokal laufen, verhindern nichts. Typprüfung, Linting, Einheiten- und End-to-End-Tests gehören in die Pipeline, und es gehört festgelegt, was einen Merge blockiert.

13:48 Der zweite Teil ist der wichtigere: Eine Prüfung, die fehlschlagen darf, ohne dass etwas passiert, ist nach zwei Wochen Dekoration. Jeder sieht das rote Kreuz, jeder merged trotzdem, und irgendwann sieht niemand mehr hin. Das ist keine Frage der Disziplin, sondern der Gestaltung. Die letzte Zeile ist die interessante — eine Messung, die nächtlich läuft und nichts blockiert.

14:11 Solche Prüfungen haben ihre Berechtigung, wenn sie Trends zeigen statt einzelne Läufe zu bewerten. Der Satz unter der Tabelle ist meine Erfahrung und meine Warnung zugleich: Was den Merge nicht blockiert, wird nach zwei Wochen ignoriert. Wenn Sie also eine Prüfung für wichtig halten, machen Sie sie blockierend. Und wenn Sie das nicht wollen, fragen Sie sich, ob Sie sie wirklich brauchen.

14:33 Der erste Punkt ist die Rechnung, die man aufmachen sollte: Ein End-to-End- Lauf von zwanzig Minuten wird umgangen, nicht abgewartet. Der zweite ist der schlimmste Zustand überhaupt — flatterhafte Tests zerstören das Vertrauen in alle anderen. Wenn ein Test manchmal rot ist, startet man ihn neu, statt hinzusehen. Und dann tut man das irgendwann auch bei den echten Fehlern.

14:55 Der dritte Punkt ist eine kleine organisatorische Regel mit großer Wirkung: Ein deaktivierter Test braucht ein Datum, sonst bleibt er für immer deaktiviert. In dieser Aufgabe wählen Sie für eine fachliche Zusage die passende Testebene und verankern sie. Der Erfolg hat zwei Teile, und der zweite ist der, der zählt: Die Tests blockieren bei Fehlschlag.

15:16 Der Hinweis für die Schnelleren ist eigentlich der Kern der ganzen Übung — entfernen Sie versuchsweise die Besitzprüfung und sehen Sie nach, ob ein Test rot wird. Wenn keiner rot wird, haben Sie Tests, aber keine Absicherung. Das ist ein Unterschied, den man nur so herausfindet.

Modul 12 zusammengefasst

15:32 Vier Sätze zum Mitnehmen. Vitest für Einheiten und Client-Komponenten, Playwright für den Durchstich. Asynchrone Server-Komponenten sind nicht direkt testbar — dafür ist der Zugriffs-Layer da. Negative Rollen-Tests sind die wertvollsten Tests im Projekt. Und der neue Testhelfer macht aus einem Geschwindigkeitsversprechen eine prüfbare Zusage.

15:53 Im nächsten Modul machen wir die Anwendung produktionsreif: Architektur, Bundle, Bilder, Messbarkeit — und der Weg in einen Container, den ein Betriebsteam betreiben kann.