Antwort.

Der Umgang mit dynamischen Erwartungen ist eine dringende Aufgabe im Bereich der UI-Automatisierung, insbesondere für moderne Webanwendungen, bei denen Inhalte oft nicht sofort erscheinen und sich ändern.

Geschichte der Frage In den frühen Versionen der Automatisierung wurden starre Erwartungen (sleep) verwendet, die Tests entweder zu langsam oder flakey machten, wenn Anwendungen länger als gewöhnlich geladen wurden. Dies wurde in der Ära von SPA und heavy JS relevant.

Problem Die Verwendung statischer Verzögerungen führt zu instabilen Tests und Zeitverlust: Autotests können zufällig hängen bleiben oder "fehlschlagen". Außerdem leidet die Skalierbarkeit und Wartbarkeit der Tests.

Lösung Verwenden Sie dynamische (explizite) Erwartungen: zum Beispiel WebDriverWait in Selenium, die Funktion waitFor in den Frameworks Cypress und Playwright.

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, 10)  # maximales Warten von 10 Sekunden
wait.until(EC.visibility_of_element_located((By.ID, 'my-element')))

Wichtige Merkmale:

Verwenden Sie explizite Erwartungen nur dort, wo es nötig ist
Keine doppelten Erwartungen für dasselbe Ereignis
Klare Definition der Bedingungen, unter denen die Erwartung endet (sichtbar/klickbar/usw.)

Fangfragen.

Warum ist sleep notwendig, wenn es dynamische Erwartungen gibt?

Die Verwendung von time.sleep() ist nur für Debugging oder in extremen Fällen gerechtfertigt. In realen Autotests ist es besser, immer explizite Erwartungen zu machen.

Kann die Verwendung von Erwartungen Flakiness vollständig ausschließen?

Nein, wenn die Erwartungen unzureichend beschrieben sind (zum Beispiel, wenn wir auf das Auftreten eines Attributs warten, anstatt auf das vollständige Laden der Daten), bleibt die Flakiness bestehen.

Kann man eine globale Erwartung für alle Tests machen?

Nein - die Bedingungen für das Auftreten von Elementen sind unterschiedlich. Erwartungen müssen strikt auf die Schritte angewendet werden, wo es notwendig ist.

Typische Fehler und Anti-Muster

Verwendung von sleep anstelle von Erwartungen
Wiederholte Erwartungen, wo sie nicht nötig sind
Zu lange Timeouts, die das Auffinden echter Fehler behindern

Beispiel aus dem Leben

Negativer Fall

Alle Autotests wurden mit sleep(2) zwischen dem "Klick" und der Überprüfung geschrieben. Nach dem Aktualisieren der Seite beklagten sich die Benutzer über Verzögerungen, und die Tests fielen gelegentlich aufgrund langsamen Internets aus.

Vorteile:

Ohne Wartungscode sind die Tests einfach

Nachteile:

Tests dauern lange
Flakey Ausfälle
Passen sich nicht an die tatsächliche Geschwindigkeit der Anwendung an

Positiver Fall

Wir haben explizite Erwartungen für das Laden von Blöcken gesetzt, der Klick wurde möglich, nachdem die erforderlichen Elemente erschienen. Wir haben auf sleep verzichtet, alle Tests laufen stabil und schnell.