Antwort.

Hintergrund:

Das Aufkommen moderner Single Page Applications (SPAs) auf Basis von React, Angular, Vue hat neue Probleme bei der Automatisierung von UI-Tests mit sich gebracht: asynchrone Datenladung, komplexe dynamische UI-Elemente, Client-seitiges Routing. Klassische Ansätze (z. B. basierend auf Selektoren oder statisch gerendertem DOM) sind für solche Anwendungen nicht mehr zuverlässig.

Problem:

Tests "fallen" häufig aufgrund von Ladeverzögerungen, Animationen und asynchronen Änderungen von Elementen aus.
Instabilität von Selektoren (dynamische IDs, Klassen, Änderungen in der DOM-Struktur).
Schwierigkeit bei der Wartung der Tests nach Änderungen auf der Frontend-Seite.

Lösung:

Verwendung von expliziten Erwartungen (explicit waits) auf das Erscheinen oder die Änderung von Elementen:

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 20)
my_element = wait.until(EC.visibility_of_element_located((By.ID, 'dynamic_id')))

Arbeiten mit stabileren Lokatoren (data-testid, einzigartige Attribute).
Organisation der Testinfrastruktur: Mocking von API-Antworten, Verwendung spezieller Test-Helpers.
Einbeziehung spezieller Hooks oder stabiler Test-IDs im Frontend.

Wesentliche Merkmale:

Fokus auf stabile Lokatoren und explizite Erwartungen
Validierung des UI-Zustands über API oder Dienstereignisse
Automatisierung "in Schichten": Unit + Integration + E2E

Trickfragen.

Kann man sich in Tests für SPAs nur auf XPATH oder CSS-Lokatoren verlassen?

Nein. Lokatoren wie XPATH/CSS brechen häufig bei Änderungen im DOM. Besser sind stabile data-* Attribute oder test-IDs, die speziell in Elemente integriert werden.

Löst Selenium/WebDriverWait alle Probleme der Asynchronität?

Nein. WebDriverWait hilft, Ausfälle aufgrund von Verzögerungen zu vermeiden, garantiert jedoch nicht ein korrektes Laden und Zustand einer komplexen UI. Zusätzliche Überprüfungen, API-Mocking und die Arbeit mit UI-Zuständen sind erforderlich.

Reicht es aus, nur die Sichtbarkeit von Elementen auf der Seite zu überprüfen, um die Korrektheit des UI-Ladens zu bestätigen?

Nein. Man könnte fälschlicherweise ein "leeres" Laden als erfolgreich ansehen, wenn ein Element angezeigt wird, jedoch nicht die erwarteten Daten oder Zustände enthält. Es ist notwendig, den Inhalt und die Werte der Felder zu validieren.

Typische Fehler und Anti-Patterns

Verwendung dynamischer oder instabiler Lokatoren
Implizite Erwartungen (Sleep anstelle von expliziten Erwartungen)
Überprüfung nur der Existenz eines Elements, ohne dessen Wert/Inhalt zu prüfen
Fehlendes Mocking von API-Antworten/Diensten

Beispiel aus der Praxis

Negativer Fall

Automatisierungstests werden regelmäßig ausgeführt, verwenden XPath-Selektoren und Sleep-Verzögerungen. Nach einem UI-Update fallen die Hälfte der Tests aufgrund fehlender Elemente oder ihrer Verschiebung mit neuer ID/Klasse aus.

Vorteile:

Schnelle Erstellung von Automatisierungstests
Einfache Struktur

Nachteile:

Instabilität (flaky tests)
Schwierigkeit bei der Unterstützung jeder Version

Positiver Fall

Im UI werden data-testid eingeführt, die Tests verwenden explizite Erwartungen und spezielle Test-Hooks. Alle Netzwerkantworten werden gemockt, die Tests validieren nicht nur die Existenz, sondern auch den Inhalt der Elemente.