Odpowiedź.

Praca z dynamicznymi oczekiwaniami to palący temat w dziedzinie automatyzacji UI, szczególnie w nowoczesnych aplikacjach internetowych, gdzie zawartość często pojawia się i zmienia nie natychmiastowo.

Historia pytania W wczesnych wersjach automatyzacji stosowano twarde oczekiwania (sleep), które sprawiały, że testy były albo zbyt wolne, albo niestabilne, jeśli aplikacje ładowały się dłużej niż zwykle. Stało się to istotne w erze SPA i heavy JS.

Problematyka Używanie statycznych opóźnień prowadzi do niestabilnych testów i marnowania czasu: test automatyczny może spowalniać lub "nie przechodzić" losowo. Ponadto cierpi na tym skalowalność i wsparcie testów.

Rozwiązanie Używaj dynamicznych (jawnych) oczekiwań: na przykład WebDriverWait w Selenium, funkcji waitFor w frameworkach Cypress i 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)  # maksymalne oczekiwanie 10 sekund
wait.until(EC.visibility_of_element_located((By.ID, 'my-element')))

Kluczowe cechy:

Używanie jawnych oczekiwań tylko tam, gdzie to konieczne
Nie dublować oczekiwań dla tego samego zdarzenia
Jasne określenie warunków, po których kończy się oczekiwanie (widoczność/kliknięcie/itp.)

Pytania z zaskoczeniem.

Po co jest sleep, skoro są dynamiczne oczekiwania?

Użycie time.sleep() jest uzasadnione tylko do debugowania lub w skrajnych przypadkach. W rzeczywistych autotestach lepiej zawsze robić jawne oczekiwania.

Czy użycie oczekiwań może całkowicie wyeliminować flakey?

Nie, jeśli warunki oczekiwania są opisane nieadekwatnie (na przykład czekamy na pojawienie się atrybutu, a nie pełne załadowanie danych), flakey pozostaną.

Czy można zrobić jedno globalne oczekiwanie dla wszystkich testów?

Nie — warunki pojawiania się elementów różnią się. Oczekiwania należy stosować ściśle do tych kroków, gdzie to konieczne.

Typowe błędy i antywzorce

Używanie sleep zamiast oczekiwań
Powtarzające się oczekiwania tam, gdzie nie są potrzebne
Zbyt długie czasy oczekiwania, które utrudniają wychwytywanie prawdziwych błędów

Przykład z życia

Negatywny przypadek

Wszystkie testy automatyczne były napisane z sleep(2) między "kliknięciem" a weryfikacją. Po zaktualizowaniu strony użytkownicy skarżyli się na opóźnienia, a testy czasami zawodziły z powodu wolnego internetu.

Plusy:

Bez kodu oczekiwań testy są proste

Minusy:

Testy trwają długo
Flakey upadki
Nie dostosowują się do rzeczywistej prędkości aplikacji

Pozytywny przypadek

Ustaliliśmy jawne oczekiwania dla ładowania bloków, kliknięcie stało się możliwe po pojawieniu się wymaganych elementów. Zrezygnowaliśmy z sleep, wszystkie testy przechodzą stabilnie i szybko.