Eigenschaften guter Test-IDs

Ausführliche Richtlinien für stabile, sprechende und DRY-konforme Test-IDs.

Heilige Dreifaltigkeit (Orientierung): 👤 Abstrakter Bezeichner · ✨ Konkreter Lokator (Fleischwerdung) · 🛠️ Widget/Adapter (Interaktion)

Test-IDs (z. B. data-testid, automation-id, Swing-setName) sind das Rückgrat der Automatisierung. Hier sammeln wir die ausführlichen Kriterien, die eine gute Test-ID erfüllen sollte.

---

1. Eindeutigkeit & Stabilität

• Global eindeutig: jede ID existiert applikationsweit nur einmal.

• Stabil über Releases: einmal vergeben ⇒ bleibt erhalten.

• Deterministisch: ableitbar aus Domäne/Kontext, nicht aus Layout.

• Nicht Layout-basiert: keine CSS-Klassen, keine Indexe, keine Reihenfolgen.

---

2. Sprechend & domänennah

• Fachlich statt technisch: customer.search.submit statt btn123.

• Sinnvolle Granularität: nicht zu generisch (button1), nicht zu detailreich (searchButtonGreenRightTop).

• Keine UI-Technik im Namen: „Button“, „Div“, „Xpath“ bleiben in den Adaptern.

---

3. Namensschema & Konventionen

• Namespaces: <domäne>.<kontext>.<funktion>[.<variante>].

  • Beispiel: customer.search.submit, invoice.row.{invoiceId}.amount.

• Zeichenmenge: [a-z0-9_.-].

• Kleinschreibung und Punkt-Notation für Lesbarkeit.

• Keine Umlaute, keine Leerzeichen, keine Sonderzeichen.

• Länge: kurz genug zum Tippen, lang genug zur Eindeutigkeit (≈ 20–60 Zeichen).

• Mehrfachinstanzen: mit stabilem Schlüssel statt Index ({invoiceId} statt row[3]).

---

4. Lebenszyklus & Governance

• Zentrale Registry: alle IDs in einer Datei (locator-ids.yaml).

• Review-Prozess: Änderungen nur via Pull-Request + Review (Dev + QA).

• Deprecation-Policy: alte IDs min. 1 Release als Alias belassen, dann entfernen.

• Versionierung: Registry im Git, Änderungen sind nachvollziehbar.

---

5. Technische Anforderungen

• Maschinenlesbar: simpler String, keine Logik.

• Performant: Zugriff in O(1), kein DOM-Wildwuchs.

• Unsichtbar für Endnutzer: IDs tauchen nicht in der UI auf.

• a11y-neutral: darf Accessibility nicht stören; nicht verwechseln mit aria-*.

---

6. Sicherheit & Datenschutz

• Keine PII: keine Namen, IBANs, Vorgangsnummern etc.

• IDs ≠ Geschäftslogik: dürfen keine Autorisierungs- oder Geschäftsentscheidungen triggern.

• Logging: IDs sollen unkritisch geloggt werden können.

---

7. Internationalisierung

• Sprachneutral: IDs bleiben gleich, egal ob die UI deutsch, englisch oder japanisch ist.

• Keine Übersetzungen in IDs.

• Einheitlich englisch/neutral als Standard.

---

8. Plattform-Übertragbarkeit

• Eine Quelle, viele Targets: abstrakte ID (customer.search.submit) wird in Web, Swing oder Mobile konkretisiert.

• Generator baut pro Plattform die passenden Locator-Ausdrücke.

Beispiel:

# locator-ids.yaml
- id: customer.search.submit
  intent: "Suche auslösen"

Web:

[data-testid="customer.search.submit"]

Swing:

component.setName("customer.search.submit");

---

9. Kompatibilität & Migration

• Aliases für Umbenennungen:

  current: customer.search.submit
  aliases: [ customer.search.searchSubmit ]

• CI-Check warnt bei Alias-Nutzung → sanfte Migration.

---

10. Tooling & Qualitätssicherung

• Linting: prüft Namensschema, verbietet Duplikate, scannt nach PII.

• Doc-Gen: Registry automatisch als HTML/MD-Doku exportieren.

• Coverage-Report: ungenutzte IDs finden.

• „Red Button“-Check: jeder interaktionsrelevante Control muss eine ID haben. → Build bricht, wenn IDs fehlen.

---

11. Anti-Patterns (bitte vermeiden)

❌ IDs aus Layout ableiten:

page > div:nth-child(3) .btn.blue

❌ Indexbasierte IDs:

list.item[0].title

❌ Fachdaten als ID:

customer.anna.mueller.submit

❌ Technik-Bezeichner:

btnSubmit, div-123

❌ Sprachabhängige IDs:

kunde.suche.absenden

---

Zusammenfassung

Eine gute Test-ID ist eindeutig, stabil, sprechend, neutral, zentral gepflegt und generierbar. Sie ist das Verbindungsstück zwischen abstraktem Bezeichner (Vater) und Interaktion (Heiliger Geist) – die Fleischwerdung der Automatisierung. ✨