Entwurfsmuster in der Testautomatisierung sind bewährte, wiederverwendbare Lösungen, die Testcode strukturiert, lesbar und erweiterbar halten. Zu den wichtigsten gehören Page Object, das die Elemente einer Webseite in Klassen kapselt, Builder, der die Erzeugung eines Objekts von seiner Darstellung trennt, und Facade, die gruppierte Funktionen über einen einzigen Einstiegspunkt erreichbar macht. Flankiert werden sie von den Prinzipien DRY (do not repeat yourself), KISS (keep it simple) und YAGNI (you aren’t gonna need it).
Das Wichtigste in Kürze
- Entwurfsmuster geben Teams in der Testautomatisierung ein gemeinsames Vokabular: Statt eine Lösung jedes Mal von vorn zu erklären, reicht der Name des Musters (Builder, Singleton, Facade).
- Spaghetti-Testcode entsteht direkt aus fehlender Kapselung: Ohne Muster wie Page Object verteilen sich Selektoren und Methoden über alle Tests, und die Duplikate vervielfachen sich.
- Das YAGNI-Prinzip gilt auch für Testautomatisierungs-Frameworks: Nur bauen, was jetzt gebraucht wird, und Erweiterbarkeit als Option in der Struktur anlegen, nicht als Haufen ungenutzter Hilfsfunktionen.
- KI-Tools erzeugen ohne klare Vorgaben im Prompt überkomplizierten Testautomatisierungscode, und ein Mensch muss das Ergebnis weiterhin prüfen und umbauen.
- Die 1994 veröffentlichten Entwurfsmuster der Gang of Four lassen sich bis heute direkt in der Testautomatisierung einsetzen, allen voran die Erzeugungsmuster. Der Objektpool, der nicht aus dem Gang-of-Four-Katalog stammt, hilft bei der Verwaltung paralleler WebDriver-Instanzen.
Warum Entwurfsmuster in den Testcode gehören
Code für die Testautomatisierung ist echter Code und verdient dieselbe Sorgfalt wie das Produktivsystem, das er prüft. Kostiantyn Teltov ist seit fast zwanzig Jahren im Softwaretest unterwegs, mit technischem Hintergrund in C#, Java, JavaScript, TypeScript und Python. Seine Haltung ist eindeutig: Pflege deinen Testautomatisierungscode, denn er wächst und lebt länger als der schnelle Prototyp, mit dem alles angefangen hat.
Entwurfsmuster übernehmen dabei vier Aufgaben. Sie liefern eine erprobte Lösung, statt das Rad neu zu erfinden. Sie bringen objektorientierte Prinzipien in den Code und verhindern so, dass er zu Spaghetti wird. Sie schaffen ein gemeinsames Vokabular im Team. Und sie machen den Code erweiterbar, damit das kleine Framework von heute morgen mitwachsen kann.
Der letzte Punkt ist der, der sich im Alltag auszahlt. Eine Testsuite, die als Prototyp startet, wird oft zum Rückgrat einer größeren Lösung. Muster sorgen dafür, dass sie wachsen kann, ohne unter ihrem eigenen Gewicht zusammenzubrechen.
Welches Problem das Page Object Pattern löst
Das Page Object ist das verbreitetste Muster in der UI-Testautomatisierung, und es ist dazu da, Duplikate zu verhindern. Ohne dieses Muster schreibst du alle Selektoren und Methoden direkt in die Tests und wiederholst sie jedes Mal, wenn du denselben Screen testest.
Ein Page Object kapselt einen Screen oder eine Webseite in einer Klasse. Ist die Seite groß, teilst du sie in Unterklassen für die kleineren Bereiche auf. Selektoren und WebDriver-Aufrufe liegen an einer Stelle, und die Tests greifen darauf zu.
Das funktioniert unabhängig von Programmiersprache und Test-Framework. Page Objects sind die gemeinsame Basis, zu der fast jeder UI-Automatisierer als Erstes greift. Genau deshalb sind sie der naheliegende Einstieg ins Denken in Mustern.
Builder, Facade und Objektpool: drei Muster, die sich lohnen
Neben dem Page Object haben sich einige weitere Muster in der Automatisierung bewährt. Kostiantyn hebt den Builder und die Facade hervor. Dazu kommt ein Muster, das nicht aus dem Gang-of-Four-Katalog stammt: der Objektpool, der ein ganz bestimmtes Performance-Problem löst.
Der Builder trennt die Erzeugung eines Objekts von seiner Darstellung. Das Bild dazu ist ein Burger: Aus einem Konstruktor baust du einen Cheeseburger oder einen Hamburger, je nachdem, welche Zutaten du zusammenstellst. Im Test liest sich das sehr sauber. Auch ohne ein komplettes BDD-Framework wie Cucumber oder SpecFlow wird das Test-Setup mit einem Builder fast genauso lesbar, weil die einzelnen Bauschritte zeigen, was der Test braucht.
Die Facade funktioniert wie ein Empfangstresen. Du kommst bei einer Klasse an und erreichst von dort alles, was du brauchst. Bei einer API gelangst du über eine Facade zu Benutzern, Kunden oder Bestellungen, ohne in jedem Test dieselbe Initialisierung zu wiederholen. Die ähnlichen Klassen, etwa die REST-Request-Builder, richtest du einmal ein, und die Tests laufen über den einen Einstiegspunkt.
Der Objektpool hilft gegen ständig schwankenden Speicherverbrauch. Stell dir vor, du erzeugst WebDriver-Instanzen parallel und schließt sie wieder, immer und immer wieder, und jedes Mal schießt der Speicherverbrauch nach oben. Statt bei jedem Lauf neu zu erzeugen und wieder abzubauen, legst du einen Pool an, nimmst einen Treiber heraus, gibst ihn zurück und räumst den Pool am Ende auf. Die Idee ist simpel, sobald sie einem jemand gezeigt hat.
Zur schnellen Orientierung, wofür welches Muster da ist:
| Muster | Problem, das es löst |
|---|---|
| Page Object | Doppelte Selektoren und WebDriver-Aufrufe in den Tests |
| Builder | Umständliches Objekt-Setup, schwer lesbarer Aufbau von Testdaten |
| Facade | Wiederholte Initialisierung und Navigation über viele Klassen |
| Objektpool | Speicherspitzen durch ständiges Erzeugen und Zerstören von Objekten |
Die Entwurfsmuster der Gang of Four tragen bis heute
Muster aus dem Jahr 1994 gelten auch Jahrzehnte später noch. Die Erzeugungsmuster der Gang of Four sind ein guter Startpunkt: Singleton, Factory Method, Abstract Factory, Builder und Prototype.
Nicht alle haben heute dasselbe Gewicht. Prototype etwa spielt in modernen Sprachen eine kleinere Rolle, weil sich Objekte dort ohnehin unter der Haube kopieren lassen. Die anderen sind weiterhin regelmäßig im Einsatz, je nachdem, was du baust.
Neben den Mustern stehen Designprinzipien. Das Dependency Inversion Principle, umgesetzt über Dependency Injection, nennt Kostiantyn als wichtig für Automatisierungs-Frameworks. Es geht nicht darum, alles anzuwenden, sondern den Katalog so gut zu kennen, dass du auswählen kannst, was die Situation verlangt.
DRY, KISS und YAGNI halten Testcode ehrlich
Don’t repeat yourself ist das Prinzip, das die meisten dieser Muster verbindet. Ein Page Object ist DRY in Reinform: Du kapselst Element-Lookups und WebDriver-Methoden, statt sie ständig zu wiederholen. Dieselbe Logik gilt für Assertions, die du mehrfach brauchst, oder für häufige Datenbankaufrufe. Alles, was nach Spaghetti aussieht, ist meistens eine Wiederholung, die in eine Hilfsfunktion gehört.
Keep it simple sichert die andere Seite ab. Du entwirfst nicht das Produkt. Du entwirfst die Tests dafür, und für deine Tests schreibst du keine Tests. Greif nur dann zu einem Muster, wenn das Problem danach verlangt, und nicht, weil du es gerade gelernt hast und endlich einsetzen willst.
“Gerade wenn man etwas Neues lernt, zum Beispiel ein neues Entwurfsmuster, will man es auch umsetzen. Aber man muss sich immer fragen, ob es hier passt, denn manchmal neigen wir dazu, zu verkomplizieren und zu überdesignen.”
(Kostiantyn Teltov)
You aren’t gonna need it macht das Trio komplett. Bau, was du jetzt brauchst. Leg das Framework so an, dass es erweiterbar bleibt, aber schreib keine Hilfsfunktionen für Anwendungsfälle, die es noch gar nicht gibt. Vorauseilendes Gerüst ist auch eine Form von Unordnung.
Wie KI mit Mustern umgeht und wo sie überkompliziert
KI kann musterbasierten Code erzeugen, aber nur, wenn du ihr den Kontext mitgibst, und das Ergebnis musst du trotzdem prüfen. KI arbeitet mit Prompts: Ein Muster taucht in der Ausgabe nur auf, wenn du danach fragst. Lässt du den Kontext weg, wendet sie auch keins an.
Die Prüfung ist wichtiger als die Generierung. Kostiantyn hatte einen Workshop vorbereitet, in dem ChatGPT ein Playwright-Framework von Grund auf erzeugt, und in der Vorbereitung klappte das gut. Einen Monat später, live und mit einem kostenpflichtigen Tarif, fing das Tool an zu verkomplizieren und stapelte eine Bedingung auf die nächste. Er musste die Ausgabe von Hand umbauen und den Teilnehmenden offen sagen, dass die generierte Fassung nicht korrekt war.
Die Lehre daraus heißt Kontrolle, nicht Verzicht. KI wird immer leistungsfähiger, aber ob der erzeugte Code angemessen oder aufgebläht ist, entscheidet weiterhin der Mensch. Und das kannst du nur, wenn du die Muster selbst kennst.
Vom Copy-Paste zur Sicherheit: wie du Entwurfsmuster wirklich lernst
Die meisten Automatisierer fangen mit Kopieren an. Du kommst in ein Team, die erfahrenen Kolleginnen und Kollegen geben dir Frameworks und Vorlagen, und du arbeitest dich per Copy-Paste durch die ersten Aufgaben. Das ist ein normaler Anfang, aber kein Endzustand.
Weiter geht es über drei Bereiche: objektorientierte Programmierung, wo sie gebraucht wird, Datenstrukturen und Entwurfsmuster. Viele in der Testautomatisierung kommen aus dem manuellen Test und nicht aus der Entwicklung. Diese Grundlagen sind deshalb nicht immer da, und es lohnt sich, sie gezielt aufzubauen.
Als Quellen nennt Kostiantyn das Originalbuch der Gang of Four, die Website Refactoring Guru mit ihren illustrierten Erklärungen in mehreren Sprachen, kostenloses Material auf YouTube sowie Plattformen wie LinkedIn Learning und Udemy. Lesen lohnt sich nach wie vor, auch wenn lange Texte aus der Mode gekommen sind.
Was bei ihm am besten funktioniert hat, war der gemeinsame Weg. Sein Team traf sich einmal pro Woche im Büro, bereitete kurze Präsentationen vor und löste dann zusammen praktische Aufgaben mit einem vorgegebenen Muster. Kolleginnen und Kollegen, die dich fordern, bringen dich genauso weiter wie jedes Buch.
Wissen wandert, wenn Teams ihre Blasen verlassen
Muster setzen sich schneller durch, wenn eine Organisation sie über Teamgrenzen hinweg teilt. Bei seinem Arbeitgeber hat Kostiantyn eine QA-Gilde mitgegründet, die erste Gilde im Unternehmen, nachdem er bei der Personalabteilung dafür geworben hatte.
Die Gilde hatte einen klaren Zweck: Wissen verbreiten und Blasen aufbrechen. Jedes Team arbeitet etwas anders und setzt auf eigene Ansätze, und in solchen Silos bleiben gute Praktiken hängen. Eine Gilde ist der Kanal, über den sie weiterwandern.
Damit schließt sich der Kreis zu einem der vier Gründe für Muster. Ein gemeinsames Vokabular funktioniert nur, wenn es auch wirklich geteilt wird. Stößt jemand im Team auf ein Problem, hilft ein “Lös das mit einem Builder” oder “Nimm hier ein Singleton” nur, wenn beide Seiten dieselbe Sprache sprechen. Eine Gilde sorgt dafür, dass diese Sprache in der ganzen Organisation ankommt.
Häufig gestellte Fragen
Braucht Code für die Testautomatisierung dieselbe Design-Disziplin wie Produktionscode?
Ja. Testcode wächst und überdauert den schnellen Prototyp, als der er begann, und eine Testsuite, die als Experiment startet, wird oft zum Rückgrat einer größeren Lösung. Entwurfsmuster bieten hier vier Vorteile: eine bewährte Lösung statt das Rad neu zu erfinden, eine funktionierende objektorientierte Struktur, ein gemeinsames Vokabular im Team und Spielraum, das Framework später zu erweitern.
Was verwandelt eine UI-Testsuite in Spaghetti-Code?
Fehlende Kapselung. Wenn Selektoren und Web-Driver-Aufrufe direkt in den Tests stehen, werden sie jedes Mal wiederholt, wenn jemand denselben Screen testet, und die Duplikate vermehren sich. Das Page-Object-Muster verlagert einen Bildschirm oder eine Seite in eine eigene Klasse, mit Unterklassen für die kleineren Teile großer Seiten. Die Tests greifen dann auf diese Klasse zurück, anstatt die Details selbst zu enthalten.
Kann man Test-Setups lesbar gestalten, ohne ein BDD-Framework zu verwenden?
Ja. Ein Builder trennt die Objekterstellung von der Darstellung, sodass die Konstruktionsschritte im Test genau beschreiben, was der Test tatsächlich benötigt. Stell dir das Zusammenstellen eines Burgers vor: Aus einem Konstruktor erzeugst du einen Cheeseburger oder einen Hamburger, indem du die Bestandteile auswählst. Das kommt der Lesbarkeit von Cucumber oder SpecFlow nahe, ohne ein vollständiges BDD-Framework einzubinden.
Wie geht man mit Speicher-Spitzen um, wenn Web-Treiber parallel erstellt und geschlossen werden?
Verwende einen Objektpool. Anstatt bei jedem Durchlauf einen Treiber zu erstellen und wieder zu löschen, richtest du einmalig einen Pool ein, nimmst einen Treiber daraus, gibst den Treiber nach der Nutzung zurück und räumst den Pool am Ende auf. Der Objektpool ist zwar kein Teil des „Gang of Four“-Katalogs, löst dieses spezifische Leistungsproblem aber direkt.
Sind die Entwurfsmuster der „Gang of Four“ auch Jahrzehnte nach ihrer Veröffentlichung noch nützlich?
Im Großen und Ganzen ja. Der 1994 veröffentlichte Katalog gilt nach wie vor für die Testautomatisierung, und die Erzeugungsmuster sind ein sinnvoller Ausgangspunkt: Singleton, Factory Method, Abstract Factory, Builder und Prototype. Das Prototype-Muster hat in modernen Sprachen an Bedeutung verloren, da das Kopieren von Objekten bereits im Hintergrund erfolgt. Das Prinzip der Abhängigkeitsumkehr, umgesetzt durch Dependency Injection, ist für Testautomatisierungsframeworks von Bedeutung.
Wann solltest du ein Entwurfsmuster nicht anwenden?
Wenn das Problem keines erfordert. Eine häufige Falle ist, ein neues Muster zu lernen und dann nach einer Stelle zu suchen, an der man es anwenden kann, was zu Überdesign führt. Du entwirfst Tests für ein Produkt, nicht das Produkt selbst, und du schreibst keine Tests für deine Tests. YAGNI gilt ebenfalls: Erstelle, was gerade benötigt wird, und behalte die Erweiterbarkeit als strukturelle Option offen, nicht als ungenutzte Hilfsfunktionen.
Kann KI zuverlässig musterbasierten Code für die Testautomatisierung generieren?
Nur mit explizitem Kontext im Prompt, und die Ausgabe muss trotzdem noch von einem Menschen überprüft werden. Kostiantyn Teltov hat einen Workshop vorbereitet, bei dem mit ChatGPT ein Playwright-Framework von Grund auf generiert wurde, und während der Vorbereitung funktionierte das gut. Einen Monat später, im Live-Betrieb mit einem kostenpflichtigen Tarif, fing das Tool an, eine Bedingung nach der anderen anzuhäufen. Er hat das Ergebnis von Hand überarbeitet und den Teilnehmern erklärt, dass die generierte Version nicht korrekt war.
Wie kann ein Automatisierungsingenieur über das bloße Kopieren und Einfügen bestehender Frameworks hinauskommen?
Baue gezielt drei Grundlagen auf: objektorientierte Programmierung, wo es die Anforderungen erfordert, Datenstrukturen und Entwurfsmuster. Viele Automatisierungsingenieure kommen eher aus dem Bereich des manuellen Tests als aus der Entwicklung, daher fehlen diese Kenntnisse oft. Nützliche Quellen sind unter anderem das Originalbuch der „Gang of Four“, die illustrierten Erklärungen auf Refactoring Guru, kostenloses YouTube-Material, LinkedIn Learning und Udemy. Wöchentliche Teamsitzungen mit kurzen Präsentationen und gemeinsamen praktischen Aufgaben haben sich ebenfalls bewährt.
