Odpowiedź.

Na początku automatyzacji testów UI główną trudnością była niestabilność testów z powodu opóźnień w pojawianiu się elementów oraz konieczności czekania na asynchroniczne działania na stronie. Wcześniej testerzy często stosowali sztywne opóźnienia (sleep), co prowadziło do długiego wykonywania testów i niskiej stabilności.

Problem polega na tym, że aplikacje webowe stają się coraz bardziej dynamiczne. Elementy pojawiają się i znikają asynchronicznie, a jednoczesna praca frontend i backend może powodować sytuacje, w których testy kończą się błędem z powodu niewłaściwego oczekiwania na stan UI. Statyczne przerwy, takie jak Thread.sleep(1000), tylko zwiększają czas testowania i nie gwarantują pomyślnego przejścia testu.

Rozwiązanie — stosować oczekiwania jawne i niejawne (explicit/implicit waits), które pozwalają na bardziej elastyczne i efektywne synchronizowanie działań z aktualnym stanem interfejsu. Na przykład, w Selenium lub podobnych frameworkach używa się WebDriverWait lub jego analogów do sprawdzania pojawienia się potrzebnych elementów zgodnie z warunkiem:

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)
element = wait.until(EC.presence_of_element_located((By.ID, "myElem")))

Kluczowe cechy:

Krótszy czas przestoju testów: testy kontynuują się natychmiast po spełnieniu warunku.
Zmniejszenie odsetka fałszywych trafień (flaky tests) z powodu dynamiki UI.
Wyższy poziom abstrakcji (oczekiwania według złożonych warunków, na przykład po zmianie wartości tekstowej lub zniknięciu elementów).

Pytania z podchwytliwością.

Dlaczego lepiej nie używać tylko niejawnych oczekiwań (implicit waits) zamiast jawnych?

Niejawne oczekiwania mają zastosowanie do całego kierowcy i mogą prowadzić do nieoczekiwanych opóźnień lub konfliktów z jawnymi oczekiwaniami, co często prowadzi do błędów „TimeoutException”.

Czy warto używać Thread.sleep do oczekiwań w testach UI?

Użycie Thread.sleep jest zdecydowanie niewskazane: prowadzi do zbędnych opóźnień i niestabilności testów. Lepiej używać jawnych oczekiwań i warunków.

Co robić, jeśli element pojawia się z animacją?

Czekać na pojawienie się nie tylko samego elementu, ale także jego stanu (na przykład widoczności lub klikniości), używając specjalnych warunków takich jak visibility_of_element_located.

Typowe błędy i antywzorce

Zastosowanie fikcyjnych timeoutów (sleep) zamiast warunków.
Konflikt między jawnymi a niejawymi oczekiwaniami.
Oczekiwanie na istnienie elementu, podczas gdy potrzebna jest jego widoczność lub gotowość do interakcji.

Przykład z życia

Negatywny przypadek

W projekcie oczekiwanie na pojawienie się okna modalnego zrealizowano przez Thread.sleep(3000). Czasami okno pojawiało się szybciej, a czasami wolniej. Skrypty działały wolno, a przy zwiększonej ilości obciążenia testy czasami zawodziły.

Zalety:

Prosta implementacja.
Szybka realizacja bez zagłębiania się w synchronizację.

Wady:

Niestabilność testów.
Wydłużony czas przechodzenia automatycznych testów we wszystkich środowiskach.
Trudność w utrzymaniu przy modyfikacjach UI.

Pozytywny przypadek

Przeorganizowano logikę — wszystkie działania z UI zostały owinięte w funkcje z jawnymi oczekiwaniami widoczności i aktywności elementów, wszystko przyspieszyło, a stabilność wzrosła do 98%.