# DRY bei Lokatoren

**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](https://openkeyword.gitbook.io/test-automation-principles/02_dry-prinzip/lokatoren/test-ids-checkliste) – die kurze 5-Punkte-Checkliste
* [Eigenschaften guter Test-IDs](https://openkeyword.gitbook.io/test-automation-principles/02_dry-prinzip/lokatoren/test-ids-eigenschaften) – ausführlich & mit Anti-Patterns
* [Kontext-Scoping (Übersicht)](https://openkeyword.gitbook.io/test-automation-principles/02_dry-prinzip/lokatoren/kontext-scoping) – Einstieg ins Thema
  * [Prinzip](https://openkeyword.gitbook.io/test-automation-principles/02_dry-prinzip/lokatoren/kontext-scoping/prinzip) – Grundmuster „Fenster setzen, Kinder relativ suchen“
  * [Umsetzung](https://openkeyword.gitbook.io/test-automation-principles/02_dry-prinzip/lokatoren/kontext-scoping/umsetzung) – Detail mit `Select Window` und `.//`-Notation
* [Generator-Prinzip](https://github.com/Hrabovszki1023/test-automation-principles/blob/main/02_dry-prinzip/lokatoren/generator-prinzip.md) – Fenster einmal definieren, Kinder automatisch ableiten
* [Beispiele aus Swing & Web](https://github.com/Hrabovszki1023/test-automation-principles/blob/main/02_dry-prinzip/lokatoren/beispiele.md) – konkrete Codeausschnitte zum Anfassen

***

## Einordnung in die „Heilige Dreifaltigkeit“

> 💡 **Infokasten**: Die Testautomatisierungs-Trinität
>
> 1. **Abstrakter Bezeichner** – der **Vater**: gibt dem Objekt seinen Namen (fachlich/funktional).
> 2. **Konkreter Lokator** – der **Sohn**: die „Fleischwerdung“ des Abstrakten, sichtbar und greifbar in der technischen Welt (XPath, `data-testid`, Swing-`setName`, …).
> 3. **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](https://github.com/Hrabovszki1023/test-automation-principles/blob/main/02_dry-prinzip/lokatoren/auto-healing-kritik.md) –\
  warum KI-basierte „Wunderheilungen“ nur Symptome kaschieren und DRY brechen.

***

👉 Ziel: Lokatoren **eindeutig, stabil und sprechend** gestalten –\
und dabei **einmal definieren, überall nutzen**.
