Wartbarkeit mit Fixtures und Domänenabstraktionen

Wartbarkeit mit Fixtures und Domänenabstraktionen

0:00 Wir haben jetzt Tests — erzeugt, geprüft, repariert. In diesem Modul geht es um die Frage, die ein halbes Jahr später über den Wert dieser Arbeit entscheidet: Lässt sich die Suite pflegen? Zwei Werkzeuge stehen dafür bereit, Page Objects und Fixtures. Beide sind gut, und beide werden regelmäßig zu früh und zu viel eingesetzt.

0:19 Deshalb dreht sich dieses Modul weniger um das Wie als um das Wann: Ab wann lohnt sich eine Abstraktion, und woran merkt man, dass sie den Tests mehr nimmt als gibt?

Erzeugte Tests refaktorieren

0:30 Zuerst der Ausgangspunkt: Wir haben Testdateien, die ein Agent geschrieben hat. Was davon räumt man auf — und was lässt man bewusst stehen? Erzeugter Code hat eine Eigenschaft, die man beim Aufräumen ausnutzen sollte: Er ist ehrlich. Was sich wirklich wiederholt, steht im Diff — man muss es nur lesen, bevor man umbaut. Refaktorieren heißt hier: technische Wiederholungen herausziehen, ohne die Aussage zu verändern.

0:56 Erzeugte Tests sind dafür ein überraschend guter Ausgangspunkt, und zwar aus einem Grund, der selten genannt wird: Sie sind ehrlich. Ein Mensch abstrahiert beim Schreiben, oft bevor er weiß, ob sich etwas wiederholt. Ein Agent schreibt stumpf auf, was er getan hat — und damit sehen Sie im Diff, was tatsächlich dreimal vorkommt und was nur einmal. Diese Information ist wertvoll.

1:18 Nutzen Sie sie, bevor Sie aufräumen. Beide Fehler sind teuer, aber unterschiedlich. Zu früh abstrahiert erzeugt eine Hülle um genau einen Aufrufer — Sie haben dann eine Datei mehr und nichts gewonnen. Zu spät abstrahiert kostet bei jeder Oberflächenänderung ein Dutzend Stellen. Und ein dritter Punkt, der oft untergeht: Jede Abstraktion versteckt etwas.

1:40 Versteckt sie zu viel, wird der Test stumm — man liest ihn und weiß nicht mehr, was er eigentlich prüft. Die Faustregel „drei gleiche Stellen" ist grob, aber sie schlägt Bauchgefühl deutlich. Vier Werkzeuge, sortiert nach dem, was sie kapseln. Eine Hilfsfunktion nimmt einen technischen Handgriff auf, ohne eigenen Zustand.

2:00 Ein Komponentenobjekt bündelt einen wiederkehrenden Bereich, etwa die Kopfzeile. Ein Page Object steht für eine Seite mit ihren Locators und Handlungen. Und eine Fixture kapselt den Ausgangszustand samt Aufräumen und wird in den Test hineingereicht. Wichtig ist die letzte Zeile der Fußnote: Ein Page Object ohne Fixture muss in jedem Test von Hand erzeugt werden.

2:22 Die beiden gehören zusammen — deshalb behandeln wir sie in diesem Modul auch nacheinander. Fünf Schritte, und der erste ist eine Bedingung: Die Tests müssen grün und stabil sein, bevor irgendetwas verschoben wird. Umbauen auf wackligem Fundament führt dazu, dass Sie hinterher nicht wissen, ob der Fehler vom Umbau kommt. Dann wiederholte Locators sammeln und benennen — noch ohne neue Datei.

2:46 Dann wiederkehrende Abläufe zu Handlungen mit fachlichem Namen bündeln. Dann Setup und Aufräumen in Fixtures ziehen. Und nach jedem Schritt die Suite laufen lassen. Der Diff bleibt klein, das Risiko auch. Vier Fallen beim Aufräumen. Den Agenten den Umbau in einem Zug machen zu lassen klingt effizient und endet mit einem Diff, den niemand liest — dabei ist gerade hier das Lesen die Arbeit.

3:10 Assertions in Hilfsfunktionen zu verstecken nimmt dem Test seine Aussage; sie gehören sichtbar in den Test. Für jede Seite ein Page Object anzulegen, auch für die mit einem einzigen Feld, erzeugt Bürokratie ohne Nutzen. Und Abstraktionen zu bauen, solange die Suite instabil läuft, ist der Klassiker aus Punkt eins des Vorgehens.

Page Objects sinnvoll einsetzen

3:31 Damit zum bekanntesten Muster der Testautomatisierung — und zu der Frage, warum es hier ausdrücklich als eine Möglichkeit auftaucht und nicht als Pflicht. Page Objects sind das bekannteste Muster der Testautomatisierung und werden entsprechend oft überdehnt. Wir schauen uns an, was sie leisten — und woran man merkt, dass es zu viel wird.

3:50 Ein Page Object kapselt die Locators einer Seite und bietet Handlungen mit fachlichen Namen an. Es beantwortet die Frage, wie etwas bedient wird — damit der Test nur noch sagen muss, was geschieht. Das Bild dazu: Die Fernbedienung kennt die Verkabelung des Fernsehers; Sie drücken „lauter". Wichtig ist der Zusatz auf der Folie: Es ist eine mögliche Strukturierungsform, keine Standardlösung.

4:13 Kleine Testsuiten brauchen nicht automatisch ein vollständiges Page-Object-Modell — und ein Modell, das größer ist als die Tests, pflegt am Ende niemand. Achten Sie auf das, was hier fehlt: Es gibt keine einzige Assertion. Das Objekt bietet Locators und Handlungen an — was gelten soll, sagt weiterhin der Test. Diese Trennung ist der wichtigste Punkt dieser Folie.

4:36 Sobald ein Page Object anfängt zu prüfen, wandert die Aussage aus dem Test hinaus, und Sie lesen hinterher eine Klickfolge, die irgendwo im Hintergrund etwas behauptet. Zweiter Punkt: Die Handlungen heißen nach fachlichen Vorgängen, nicht nach Klicks. Das liest sich später im Test wie ein Satz. Vier Symptome, die man kennt, sobald man sie einmal gesehen hat. Das Objekt enthält Assertions und entscheidet damit über die Aussage der Tests.

5:03 Es bildet mehrere Seiten ab, weil der Weg gerade so verlief — dann ist es kein Page Object mehr, sondern eine Reisebeschreibung. Es trägt Methoden, die nur ein einziger Test benutzt. Und es wächst mit jeder Änderung, ohne dass je etwas entfernt wird. Der letzte Punkt ist der schleichendste: Abstraktionen werden fast nie zurückgebaut, weil niemand weiß, wer sie noch braucht.

5:26 Fünf Prüfschritte, wenn ein Agent Ihnen ein Page Object geschrieben hat. Namen lesen: Beschreiben sie Handlungen oder Klicks? Assertions suchen und in die Tests zurückgeben. Ungenutzte Methoden entfernen, statt sie vorzuhalten — der Agent legt gern Vorrat an. Locators auf Rollen umstellen, wo er Struktur benutzt hat. Und prüfen, ob die Klasse wirklich eine Seite abbildet; wenn nicht, teilen.

5:50 Das Ganze dauert zehn Minuten und entscheidet darüber, ob dieses Objekt in einem Jahr noch hilft oder nur noch gepflegt wird.

Wiederverwendbare Fixtures bauen

5:58 Und jetzt zu dem Werkzeug, das in Playwright den größten Hebel hat und trotzdem seltener genutzt wird als Page Objects: Fixtures. Fixtures sind in Playwright der größere Hebel, bekommen aber weniger Aufmerksamkeit. Das ändern wir jetzt, denn sie lösen gleich zwei Probleme auf einmal. Und sie sind der Grund, warum ein Playwright-Test ohne beforeEach auskommt und trotzdem alles hat, was er braucht.

6:22 Eine Fixture stellt einem Test seine Umgebung bereit: Sie baut auf, übergibt die Sache an den Test und räumt danach auf. Zwei Eigenschaften machen sie besonders: Sie ist bedarfsgesteuert — nur was ein Test anfordert, wird eingerichtet. Und sie ist kombinierbar, weil eine Fixture selbst andere anfordern darf. Das Bild dazu: ein Mise en place in der Küche.

6:44 Alles, was dieses eine Gericht braucht, steht vorbereitet bereit; alles andere bleibt im Schrank. Genau deshalb sind Tests mit Fixtures kurz, ohne etwas zu verstecken. Hier greifen beide Werkzeuge ineinander. Die Fixture erzeugt das Page Object, bringt es in den gewünschten Zustand und übergibt es an den Test. Der Test fordert danach nur noch „warenkorb" an — die Kette bis zum Browser stellt Playwright selbst her.

7:09 Achten Sie auf die Stelle nach der Übergabe: Dort steht das Aufräumen, und es läuft auch dann, wenn der Test fehlschlägt. Genau das ist der Unterschied zu Aufräumcode am Testende, der bei einem Fehler nie erreicht wird — ein Detail mit großer Wirkung auf die Stabilität der Suite. Der Unterschied ist einer der Lebensdauer. Die normale Fixture wird pro Test neu aufgebaut und abgeräumt — das ist der Standard und in fast allen Fällen richtig.

7:35 Eine Worker-Fixture existiert einmal je Prozess und wird von allen Tests darin geteilt; das lohnt sich bei teuren Ressourcen. Dazu die beiden Zusätze: automatisch, also auch ohne Anforderung, und Option, also aus der Konfiguration gespeist. Ein Satz, den Sie sich merken sollten: Geteilter Zustand in einer Worker-Fixture ist erlaubt — nur darf kein Test ihn verändern.

7:56 Sonst haben Sie die Kollisionen aus dem nächsten Modul. Ihre Aufgabe: Ziehen Sie wiederkehrendes Setup so in Fixtures, dass die Tests kürzer werden, ohne ihre Aussage zu verlieren. Zwei erzeugte Tests sollen danach ohne beforeEach auskommen und weiterhin unabhängig grün laufen. Die zweite Bedingung ist die interessante — Kürze allein ist leicht zu haben, Kürze bei erhaltener Unabhängigkeit nicht.

8:20 Wer schneller fertig ist, ergänzt eine Fixture für die angemeldete Rolle Gärtnerin; damit haben Sie die zweite Rolle vorbereitet, die uns im Abschlussmodul begegnet. Vier Punkte zum Schluss. Zustand in einer Worker-Fixture zu verändern macht Tests voneinander abhängig — und zwar auf eine Weise, die erst unter Last auffällt.

8:40 Aufräumen zu vergessen trägt Datenreste in die nächsten Tests; auch das merkt man spät. Fixtures anzulegen, die alles einrichten, was irgendein Test irgendwann braucht, verschenkt genau die Eigenschaft, die Fixtures wertvoll macht: dass sie bedarfsgesteuert sind. Und die Anmeldung in jedem Test zu wiederholen kostet Laufzeit, die Sie in der Pipeline zurückzahlen. Damit sind wir beim nächsten Thema: Parallelität.