DRY bei Lokatoren
Warum stabile Test-IDs und Kontext-Scoping der Schlüssel zu wartbarer Testautomatisierung sind.
Heilige Dreifaltigkeit (Orientierung): 👤 Abstrakter Bezeichner · ✨ Konkreter Lokator (Fleischwerdung) · 🛠️ Widget/Adapter (Interaktion)
Lokatoren sind das Fundament jeder GUI-Testautomatisierung. Und genau hier passieren die größten DRY-Verstöße:
gleiche XPath-Schnipsel an zig Stellen,
fragile CSS-Klassen-Namen als Erkennungsmerkmal,
oder Fenster-IDs, die in jedem Kindobjekt dupliziert werden.
Das Ergebnis: hohe Wartungskosten und instabile Tests.
Dieses Unterkapitel zeigt, wie man das DRY-Prinzip bei Lokatoren konsequent anwendet:
Mindestkriterien für Test-IDs – die kurze 5-Punkte-Checkliste
Eigenschaften guter Test-IDs – ausführlich & mit Anti-Patterns
Kontext-Scoping (Übersicht) – Einstieg ins Thema
Generator-Prinzip – Fenster einmal definieren, Kinder automatisch ableiten
Beispiele aus Swing & Web – konkrete Codeausschnitte zum Anfassen
Einordnung in die „Heilige Dreifaltigkeit“
💡 Infokasten: Die Testautomatisierungs-Trinität
Abstrakter Bezeichner – der Vater: gibt dem Objekt seinen Namen (fachlich/funktional).
Konkreter Lokator – der Sohn: die „Fleischwerdung“ des Abstrakten, sichtbar und greifbar in der technischen Welt (XPath,
data-testid, Swing-setName, …).Widget/Adapter-Klasse – der Heilige Geist: kapselt die Interaktion für den jeweiligen GUI-Objekttyp (Click, SetValue, Verify …).
👉 Mit diesem Dreiklang bleibt die Verantwortung klar getrennt – und das Test-Design heilig DRY. ✝️😇
Weiterführend
Kritik am Auto-Healing von Lokatoren – warum KI-basierte „Wunderheilungen“ nur Symptome kaschieren und DRY brechen.
👉 Ziel: Lokatoren eindeutig, stabil und sprechend gestalten – und dabei einmal definieren, überall nutzen.
Zuletzt aktualisiert