Vorbereitung
Als Testobjekt dient das folgende Eingabefeld aus meinem Testlab. Es validiert die eingegebene Zeichenlänge und zeigt je nach Ergebnis eine passende Fehlermeldung an – oder eben keine, wenn die Eingabe gültig ist. Probier es gerne selbst aus, bevor wir gleich den Test dazu schreiben:
Konkret verhält sich das Feld so:
- Weniger als 3 Zeichen → „Eingabe ist zu kurz”
- 3 bis 20 Zeichen → keine Fehlermeldung
- Mehr als 20 Zeichen → „Eingabe ist zu lang, maximal 20 Zeichen”
Genau dieses Verhalten wollen wir jetzt mit Playwright testen – und zwar nicht mit vier separaten, kopierten Tests, sondern mit einem einzigen, datengetriebenen Testablauf.
Wichtig dabei: Am Ende laufen weiterhin vier einzelne Tests mit vier eigenen Ergebnissen – das muss auch so sein, schließlich sind es vier unterschiedliche Szenarien. Der Gewinn liegt nicht in weniger Testläufen, sondern darin, dass die Testlogik nur noch an einer einzigen Stelle im Code steht, statt viermal kopiert zu werden.
Das Problem: Viele ähnliche Testfälle
Ein erster, einfacher Test für den Fall „weniger als 3 Zeichen” könnte so aussehen:
Das Problem: Für jede weitere Eingabelänge (3 Zeichen, 20 Zeichen, 21 Zeichen) müsste ein nahezu identischer Test kopiert und nur leicht angepasst werden – viel, viel doppelter Code für eigentlich denselben Testablauf.
Die Lösung: Ein Datensatz statt vier Tests
Statt vier fast identischer Tests wird zunächst ein Array mit Testdaten angelegt. Jeder Eintrag enthält die Eingabe, die erwartete Fehlermeldung sowie ein Flag, ob überhaupt eine Fehlermeldung erwartet wird:
Das Flag isErrorDisplayed wird gebraucht, weil nicht in jedem Testfall überhaupt eine Fehlermeldung erscheinen soll – bei gültiger Eingabe (3 oder 20 Zeichen) erwarten wir ja gerade, dass keine Meldung angezeigt wird.
Testdaten mit forEach durchlaufen
Jetzt wird das Array mit der JavaScript-Methode forEach durchlaufen. Bei jedem Durchlauf entpacken wir die drei Eigenschaften aus dem jeweiligen Objekt und erstellen daraus einen eigenen, dynamisch benannten Test:
Wichtig dabei: Der Testname muss für jeden Durchlauf eindeutig sein. Playwright akzeptiert keine mehrfach identischen Testnamen innerhalb einer Datei – deshalb wird hier mit Template-Strings (Backticks) gearbeitet und die Eingabe direkt in den Testnamen eingebaut:
test(`Validierung für Eingabe "${input}"`, ...)
So bekommt jeder generierte Test automatisch einen eigenen, sprechenden Namen, z. B. „Validierung für Eingabe ‘ab’”.
Test ausführen
Führt man die Datei jetzt aus, erzeugt die forEach-Schleife vier einzelne Testläufe – aus nur einem geschriebenen Testblock:
Wichtiger Hinweis: Hier stehen bei mir „5 passed” statt „4 passed” – npx playwright test führt standardmäßig alle Testdateien im Projekt aus, und bei mir liegt im gleichen Projekt noch die Datei zur Authentifizierung aus meinem Beitrag zu Playwright Storage State.
Auch im HTML-Report tauchen die Testfälle einzeln auf – jeweils mit dem Eingabewert im Testnamen, sodass auf einen Blick erkennbar ist, welcher Datensatz getestet wurde:
Fazit
Sobald sich mehrere Testfälle nur durch ihre Eingabedaten unterscheiden, lohnt sich der Umstieg auf Datadriven Testing fast immer.
Und der Aufwand hält sich in Grenzen: ein Array mit den Testdaten, eine forEach-Schleife und ein dynamisch generierter Testname – fertig ist ein deutlich kompakterer und wartungsärmerer Test, der sich jederzeit um weitere Fälle erweitern lässt, ohne neuen Testcode schreiben zu müssen.
Weiterführende Links
