Parallelität, Testdaten und große Suites

Parallelität, Testdaten und große Suites

0:00 Es gibt einen Moment, den fast jedes Team erlebt: Die Tests laufen einzeln tadellos, und in der Suite werden sie launisch. Meistens ist das kein Playwright-Problem, sondern ein Datenproblem. In diesem Modul schauen wir uns an, wie Playwright parallelisiert, warum Tests dabei kollidieren, und wie man Testdaten so gestaltet, dass sie einander nicht in die Quere kommen.

0:21 Zum Schluss geht es um große Suiten: Auswahl, Verteilung und die Frage, wie aus vier Teilberichten wieder ein Ergebnis wird.

Parallelität in Playwright verstehen

0:29 Zuerst das Modell. Wer weiß, was gleichzeitig läuft und was voneinander getrennt ist, versteht die meisten seltsamen Fehlschläge sofort. Das Modell dahinter ist in fünf Minuten erklärt und erspart Ihnen später stundenlange Ratespiele. Danach wissen Sie, was gleichzeitig läuft — und vor allem, was sich die Prozesse trotzdem teilen. Genau darin liegt nämlich die Ursache fast aller sprunghaften Fehlschläge.

0:53 Playwright führt Testdateien standardmäßig parallel aus, in getrennten Worker-Prozessen. Innerhalb einer Datei laufen die Tests nacheinander, es sei denn, der vollständig parallele Modus ist eingeschaltet. Wichtig ist die Trennung: Jeder Worker hat seinen eigenen Browser-Kontext und kann mit keinem anderen sprechen. Das ist eine Stärke — die Prozesse stören sich nicht — und zugleich der Grund für alle Kollisionen, über die wir gleich reden.

1:19 Denn was die Prozesse doch teilen, liegt außerhalb: die Datenbank, die Konten, die Dateien. Diese Konfiguration ist der übliche Kompromiss, und die interessante Zeile ist die mit den Workern. Lokal lässt man Playwright entscheiden — die Maschine hat Kerne, also nutzt sie sie. In der Pipeline steht dagegen eine Eins. Das wirkt zunächst falsch, ist aber die Empfehlung der Dokumentation: Ein Worker bekommt die vollen Ressourcen, und die Läufe werden dadurch verlässlicher.

1:47 Breite entsteht in CI nicht über Worker, sondern über Sharding — also über mehrere Maschinen. Dazu kommen wir im vierten Kapitel. Der Unterschied lässt sich mit einem Bild fassen: Parallelisierung ist, mehrere Kassen in einem Supermarkt zu öffnen. Sharding ist, einen zweiten Supermarkt aufzumachen. Das eine passiert auf einer Maschine, das andere verteilt auf mehrere. Beides lässt sich kombinieren, und beides ersetzt das andere nicht.

2:13 Die dritte Zeile ist ein praktischer Hinweis: Der vollständig parallele Modus verteilt einzelne Tests statt ganzer Dateien — das balanciert später auch die Shards gleichmäßig aus. Und die vierte Zeile leitet zum nächsten Punkt über. Serielle Bereiche sind die Notlösung für Tests, die voneinander abhängen — und sie kosten mehr, als man denkt. Sie geben die Isolation auf, die jeden Fehlschlag lokal hielt.

2:37 Ein Fehler am Anfang lässt alle folgenden Tests entfallen, Sie sehen also nur noch das erste Symptom. Sie verteilen sich schlecht auf Shards und bremsen den langsamsten Job. Und sie verstecken das eigentliche Problem, nämlich die Datenabhängigkeit, statt es zu beheben. Die Dokumentation formuliert das ungewohnt deutlich: Serielle Bereiche werden nicht empfohlen.

Kollisionen erkennen

2:59 Damit zur Diagnose. Kollisionen sind ein eigener Fehlertyp, und sie verhalten sich anders als alles, was wir bisher gesehen haben. Kollisionen haben ein eigenes Erscheinungsbild, und wer es einmal kennt, erkennt sie sofort wieder. Genau deshalb lohnt sich dieses kurze Kapitel: Es spart die falsche Fährte. Und wer sie kennt, sucht nicht mehr an der Stelle, an der es rot leuchtet.

3:22 Eine Kollision entsteht, wenn zwei gleichzeitig laufende Tests dieselbe Ressource verändern. Das Symptom ist charakteristisch: Ein Test ist allein grün und in der Suite rot — oder umgekehrt, was noch verwirrender ist. Und hier kommt die wichtigste Erkenntnis: Die Ursache liegt fast nie in dem Test, der fehlschlägt, sondern in dem, der zur selben Zeit lief.

3:43 Wer das nicht weiß, repariert wochenlang am falschen Ende. Es ist wie bei einem Wasserschaden — die nasse Wand ist selten dort, wo das Rohr leckt. Fünf Quellen, und sie decken erfahrungsgemäß fast alle Fälle ab. Ein gemeinsames Benutzerkonto ist die häufigste: Ein Test meldet sich ab, während der andere mitten in der Kasse steht.

4:03 Feste Datensätze führen dazu, dass ein erwarteter Bestand sporadisch nicht stimmt. Globaler Backend-Zustand macht Ergebnisse von der Reihenfolge abhängig. Dateisystem und Downloads erzeugen Zugriffskonflikte. Und gemeinsam genutzte Ports oder Dienste liefern Verbindungsfehler ohne Muster. Die Fußzeile ist die Merkregel: allein grün, in der Suite rot — fast immer Kollision.

4:27 Fünf Schritte, und der zweite ist der Trick. Erst den Fehlschlag mit Wiederholung reproduzieren, allein und in der Suite. Dann die Worker-Zahl auf eins setzen — verschwindet der Fehler, ist es eine Kollision, und Sie haben in dreißig Sekunden mehr gelernt als in einer Stunde Codelesen. Danach prüfen, welche Tests dieselben Daten oder Konten anfassen. Den Trace des Nachbartests danebenlegen und die Zeitpunkte vergleichen.

4:51 Und erst dann die geteilte Ressource benennen — vor der Lösung steht die Diagnose. Vier Fallen. Die Wiederholungen hochzusetzen und die Kollision damit unsichtbar zu machen ist besonders verlockend, weil die Pipeline sofort grün wird — das Problem bleibt und wächst. Den fehlschlagenden Test zu reparieren, obwohl der Verursacher woanders sitzt, haben wir gerade besprochen. Ein einziges Testkonto für die ganze Suite ist die Ursache Nummer eins.

5:17 Und Aufräumcode in einen Test zu legen, der bei Fehlschlag gar nicht mehr bis dorthin kommt, hinterlässt genau die Datenreste, die den nächsten Lauf stören.

Kollisionen vermeiden

5:26 Jetzt die konstruktive Seite. Und die Antwort lautet ausdrücklich nicht: weniger Parallelität. Die gute Nachricht vorweg: Sie müssen die Parallelität nicht herunterdrehen. Es reicht, den Testdaten dieselbe Eigenschaft zu geben, die der Browser-Kontext längst hat. Das klingt nach viel Arbeit und ist am Ende eine Fixture, die eine eindeutige Kennung vergibt und hinterher aufräumt — mehr steckt in den meisten Fällen nicht dahinter.

5:52 Kollisionsfreiheit entsteht durch Daten, die keinem anderen Test gehören. Jeder Test erzeugt, was er braucht, mit einem eindeutigen Merkmal — und räumt es hinterher weg, ohne sich darauf zu verlassen, dass er dazu kommt. Das ist derselbe Gedanke wie bei der Testisolation aus Modul zwei, nur eine Ebene tiefer: Der Browser-Kontext ist schon isoliert, die Datenbank ist es nicht.

6:13 Wer diesen einen Grundsatz umsetzt, kann die Worker-Zahl hochdrehen, ohne nervös zu werden. Der Kern steckt in zwei Zeilen: Die Kennung wird aus dem Worker-Index und der Test-ID gebildet. Damit können sich zwei gleichzeitige Läufe nicht überschneiden, und selbst der wiederholte Lauf desselben Tests bekommt eigene Daten. Der zweite wichtige Punkt ist die Position des Aufräumens — es steht in der Fixture, nach der Übergabe an den Test.

6:38 Das kennen Sie aus Modul acht, und hier zeigt sich der praktische Nutzen: Auch ein fehlgeschlagener Test hinterlässt keinen Müll für den nächsten. Vier Ansätze, je nach Lage. Eindeutige Daten je Test ist der Standardfall und löst das meiste. Vorbereitung über die API macht das Anlegen schnell genug, dass es sich pro Test lohnt — der Bogen zu Modul neun.

7:00 Pools für Konten oder Mandanten braucht man dort, wo Anlegen nicht möglich ist, etwa bei fremden Systemen. Und Ressourcen über Worker-Fixtures zu verwalten passt, wenn etwas teuer ist und trotzdem geteilt werden muss — dann aber lesend. Meist reicht das erste Muster; die anderen sind für die Sonderfälle. Fünf praktische Regeln. Aufräumen in die Fixture legen, nicht ans Testende — der Punkt von eben.

7:24 Idempotent aufbauen: Ein zweiter Lauf darf nicht scheitern, sonst bricht das Aufräumen den Lauf ab, statt ihn zu beenden. Verwaiste Daten regelmäßig über einen Wartungslauf entfernen, denn irgendetwas bleibt immer liegen. Testdaten am Namensschema erkennbar machen — das hilft beim Aufräumen und beim Erklären gegenüber Kollegen, die sich über die Einträge wundern.

7:46 Und den Parallelitätsgrad dort begrenzen, wo eine Ressource wirklich knapp ist. Ihre Aufgabe: Gestalten Sie die Testdaten so, dass zwei gleichzeitig laufende Tests einander nicht beeinflussen. Zwei Tests, die vorher nur nacheinander grün waren, sollen mit mehreren Workern wiederholt grün laufen. Achten Sie auf das Wort wiederholt — ein einzelner grüner Lauf beweist bei Nebenläufigkeit gar nichts, das kann Zufall sein. Nehmen Sie sich für den Nachweis mehrere Durchläufe.

8:14 Genau diese Skepsis brauchen Sie später auch bei allem, was in der Pipeline nur manchmal rot ist.

Große Suites skalieren

8:21 Bleibt die Frage, was passiert, wenn die Suite länger läuft als die Geduld reicht. Ab einem gewissen Punkt hilft keine Optimierung mehr, sondern nur noch Verteilung. Irgendwann hilft kein einzelner Test-Tuning-Trick mehr, sondern nur noch Auswahl und Verteilung. Beides bringt Playwright mit, und beides ist schnell eingerichtet.

8:39 Der Aufwand liegt eher bei der Frage, welcher Lauf zu welchem Zeitpunkt sinnvoll ist. Ab einer gewissen Größe entscheidet nicht mehr die einzelne Laufzeit, sondern die Verteilung. Playwright bietet dafür zweierlei: Auswahl über Tags und Projekte — also gar nicht erst alles laufen lassen — und Sharding über mehrere Jobs. Die Berichte der Shards werden anschließend zu einem Report zusammengeführt.

9:02 Dieser letzte Schritt wird gern vergessen, und dann liegen vier Teilergebnisse herum, die niemand liest. Ein Bericht pro Lauf ist keine Kosmetik, sondern die Voraussetzung dafür, dass jemand hinschaut. Vier Befehle, drei Strategien. Der erste teilt die Suite in vier Teile und führt den ersten aus — in der Pipeline läuft das als Matrix über vier Jobs.

9:23 Der zweite wählt über ein Tag aus, etwa alle Rauchtests. Der dritte über ein Projekt, also einen Browser. Und der vierte führt die Blob-Berichte der Shards zu einem HTML-Report zusammen. Wichtig zur Verteilung: Mit dem vollständig parallelen Modus wird auf Testebene aufgeteilt, sonst auf Dateiebene — dann sollten die Dateien ähnlich groß sein.

9:45 Die Logik dahinter ist eine Kosten-Nutzen-Abwägung nach Zeitpunkt. Bei jedem Push zählt Geschwindigkeit — eine Rauchtest-Auswahl von wenigen Minuten, sonst wartet niemand. Beim Pull Request zählt Vollständigkeit, dort ist die volle Regression richtig. Die Browsermatrix ist teuer und selten wirklich dringend, also nachts.

10:04 Und der Quarantäne-Lauf hält instabile Tests getrennt, damit sie das Hauptergebnis nicht vergiften. Die Zuordnung passiert über Tags, die im Testnamen stehen und mit dem Test mitwandern — kein zentrales Register, das veraltet. Vier Punkte zum Abschluss. Shards ohne Zusammenführung zu fahren hinterlässt vier Teilberichte und ein unklares Ergebnis.

10:25 Große Testdateien zu behalten, die sich ohne den parallelen Modus nicht verteilen lassen, macht Sharding wirkungslos. Die Browsermatrix bei jedem Push zu fahren erzeugt Wartezeit, die niemand akzeptiert — und dann wird die Pipeline umgangen. Und instabile Tests in der Hauptsuite zu lassen, bis niemand mehr Rot ernst nimmt, ist der schleichendste Schaden von allen.

10:46 Im nächsten Modul bringen wir die Suite in die Pipeline.