Explicit Wait vs Implicit Wait: waity w Selenium WebDriver, które stabilizują testy

Losowo wywalające się testy to jeden z najszybszych sposobów na utratę zaufania zespołu do całej automatyzacji. Zwykle winowajcą nie jest sama aplikacja, lecz czas. Elementy strony ładują się w różnym tempie, a skrypt próbuje na nie kliknąć, zanim w ogóle pojawią się w modelu DOM. Właśnie dlatego prawidłowe stosowanie klasy Wait jest jedną z kluczowych umiejętności w programowaniu testów.

Ten przewodnik jest dla inżynierów QA i automatyzujących, którzy chcą ograniczyć flaky testy i skrócić czas utrzymania frameworka. Wyjaśniamy, dlaczego waity mają znaczenie, czym jest klasa Wait w praktyce, co dzieje się, gdy element nie zostanie znaleziony, oraz jak działają Implicit Wait, Explicit Wait i Fluent Wait. Pokażemy też, które podejście wybrać i dlaczego Explicit Wait zwykle wygrywa.

W skrócie:

• Waity synchronizują skrypt z aplikacją, która ładuje elementy w różnym czasie.

• Gdy element nie zostanie znaleziony, WebDriver zgłasza wyjątek NoSuchElementException.

• Implicit Wait jest prosty i szybki we wdrożeniu, ale sztucznie wydłuża czas testów.

• Explicit Wait jest inteligentniejszy, bo czeka na konkretny warunek i działa dynamicznie.

• Fluent Wait dodaje kontrolę nad częstotliwością odpytywania i obsługą wyjątków.

Dlaczego waity w Selenium mają znaczenie

Podczas wykonywania skryptów automatycznych aplikacja i jej poszczególne elementy mogą odpowiadać w różnym czasie. Wpływa na to wiele czynników, takich jak obciążenie ruchu sieciowego, siła zasięgu internetu czy nieoptymalne mechanizmy aplikacyjne. W efekcie dymek komunikatu, tabela czy przycisk pojawiają się na stronie z opóźnieniem.

To rodzi realny problem. Wyobraź sobie, że skrypt ma kliknąć przycisk, którego jeszcze nie ma na stronie, bo aplikacja właśnie się ładuje pod większym obciążeniem. Bez mechanizmu oczekiwania test po prostu się wywali, choć aplikacja działa poprawnie, tylko nieco wolniej. Tego typu niestabilność, czyli flaky testy, podkopuje wiarygodność całego procesu, o czym piszemy szerzej w materiale o zaletach i wadach automatyzacji testów.

Czym jest klasa Wait w praktyce

Klasa Wait wchodzi w skład biblioteki Selenium WebDriver i jest jej integralną częścią. Jej metody stosuje się bardzo często podczas programowania skryptów testowych, bo to one rozwiązują problemy z opóźnieniami.

Mówiąc w uproszczeniu, metody klasy Wait wstrzymują na określony czas wykonywanie skryptu, zanim przejdzie on do kolejnych kroków. Dzięki temu dajesz elementowi czas na pojawienie się w modelu DOM i pełne wyrenderowanie, na przykład na załadowanie tysięcy wierszy do tabeli. Większość aplikacji internetowych korzysta z technologii Ajax oraz JavaScript, co tylko potęguje sytuację, w której elementy mają różne czasy ładowania. Pełną listę mechanizmów opisuje też oficjalna dokumentacja Selenium.

Implicit Wait, czyli oczekiwanie niejawne

Implementując Implicit Wait, dodajesz globalny timeout, który zadziała wtedy, gdy poszukiwany element nie jest widoczny od razu. W takiej sytuacji WebDriver poczeka zdefiniowaną jednostkę czasu, a dopiero po jej przekroczeniu zgłosi wyjątek NoSuchElementException.

Definicja sprowadza się do jednej linijki:

driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);

Aby korzystać z tej instrukcji, musisz zaimportować odpowiedni pakiet:

import java.util.concurrent.TimeUnit;

W tym przykładzie metoda implicitlyWait() będzie czekać maksymalnie 10 sekund. Największą zaletą tego rozwiązania jest szybkość i prostota implementacji, bo wystarczy jedna linijka, by objąć mechanizmem oczekiwania cały skrypt.

Niestety niejawne oczekiwanie ma istotne wady, które ujawniają się wraz ze wzrostem ilości kodu. Po pierwsze, sztucznie i znacznie wydłuża czas wykonywania skryptu testowego. Po drugie, działa prawidłowo tylko z metodą findElement(By by), co w wielu sytuacjach okazuje się po prostu niewystarczające. Dlatego warto ograniczyć jego użycie, a często wręcz wyeliminować na rzecz mechanizmów opisanych niżej.

Przykład zastosowania Implicit Wait

import java.util.concurrent.TimeUnit;

import org.openqa.selenium.*;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

public class WaitTest {

private WebDriver driver;
private String baseUrl;

@BeforeMethod
public void setUp() throws Exception {
System.setProperty(“webdriver.chrome.driver”, “src/main/resources/chromedriver.exe”);
driver = new ChromeDriver();
baseUrl = “http://www.selenium-shop.pl/”;

driver.get(baseUrl);
driver.manage().window().maximize();

// ImplicitWait, oczekiwanie niejawne
driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
}

@Test
public void oczekiwanie_Test() {
String correctTitle = “Moje konto – Selenium Shop Automatyzacja Testów”;

WebElement mojeKontoMenu = driver.findElement(By.linkText(“MOJE KONTO”));
mojeKontoMenu.click();

Assert.assertEquals(driver.getTitle(), correctTitle);
}

@AfterMethod
public void tearDown() throws Exception {
driver.quit();
}
}

Explicit Wait, czyli oczekiwanie jawne

Znacznie lepszym pomysłem od Implicit Wait jest stosowanie jawnego oczekiwania. W odróżnieniu od niejawnego możesz tu definiować predefiniowane, niestandardowe warunki wznawiania działania kodu.

Explicit Wait ma nieco bardziej rozbudowaną implementację. Najpierw tworzysz obiekt klasy WebDriverWait, przekazujesz mu WebDrivera oraz wartość timeoutu, a następnie wywołujesz metodę until, w której wskazujesz warunek konieczny do kontynuacji. Jawne oczekiwanie jest bardziej inteligentne, bo czeka na wystąpienie konkretnego warunku, a nie na ślepy upływ czasu.

Warto przy tym pamiętać o ważnej różnicy. Selenium ma też metody do zarządzania przeglądarką czy obsługi ciasteczek, a Implicit Wait z nimi nie współpracuje. Explicit Wait nie ma tego ograniczenia. Do efektywnej pracy wykorzystujesz klasy WebDriverWait oraz ExpectedConditions, która oferuje zbiór gotowych warunków. Najczęściej używane to:

alertIsPresent();
elementToBeClickable();
elementToBeSelected();
frameToBeAvailableAndSwitchToIt();
invisibilityOfElementLocated();
presenceOfElementLocated();
presenceOfAllElementsLocatedBy();
textToBePresentInElement();
titleIs();
titleContains();
visibilityOf();
visibilityOfElementLocated();
visibilityOfAllElementsLocatedBy();

Aby korzystać z jawnego oczekiwania, importujesz dwa pakiety:

import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

Sama inicjalizacja obiektu wait wygląda następująco, gdzie pierwszy argument to WebDriver, a drugi to maksymalny czas oczekiwania w sekundach:

WebDriverWait wait = new WebDriverWait(driver, 30);

Przykładowe użycie warunku widoczności przed kliknięciem przycisku:

// warunkowe oczekiwanie na widoczność elementu
wait.until(ExpectedConditions.visibilityOfElementLocated(By.xpath(“//button[@id=’Zaloguj’]”)));

// kliknięcie nastąpi tylko wtedy, gdy element jest widoczny
driver.findElement(By.xpath(“//button[@id=’Zaloguj’]”)).click();

Powyższy kod sprawi, że WebDriver poczeka maksymalnie 30 sekund przed zgłoszeniem wyjątku. Jeśli element pojawi się w 5 sekund, oczekiwanie potrwa dokładnie 5 sekund, a jeśli w 1 sekundę, to tylko 1 sekundę. To właśnie owa dynamika decyduje o przewadze Explicit Wait: nie marnujesz czasu na sztuczne wstrzymywanie skryptu.

Przykład zastosowania Explicit Wait

import org.openqa.selenium.*;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

public class WaitTest {

private WebDriver driver;
private String baseUrl;

@BeforeMethod
public void setUp() throws Exception {
System.setProperty(“webdriver.chrome.driver”, “src/main/resources/chromedriver.exe”);
driver = new ChromeDriver();
baseUrl = “http://www.selenium-shop.pl/”;

driver.get(baseUrl);
driver.manage().window().maximize();
}

@Test
public void oczekiwanie_Test() {
// ExplicitWait, deklaracja
WebDriverWait wait = new WebDriverWait(driver, 30);

String correctTitle = “Moje konto – Selenium Shop Automatyzacja Testów”;

// ExplicitWait, implementacja
wait.until(ExpectedConditions.visibilityOfElementLocated(By.linkText(“MOJE KONTO”))).click();

Assert.assertEquals(driver.getTitle(), correctTitle);
}

@AfterMethod
public void tearDown() throws Exception {
driver.quit();
}
}

Fluent Wait, czyli płynne oczekiwanie z parametrami

Za pomocą klasy Fluent Wait definiujesz maksymalny czas oczekiwania na element lub warunek, a dodatkowo częstotliwość sprawdzania tego warunku. Możesz też skonfigurować konkretne typy wyjątków, które mają być ignorowane podczas wyszukiwania, na przykład NoSuchElementException.

Mechanizm jest podobny do Explicit Wait, ale daje większą kontrolę. Fluent Wait może wielokrotnie odpytywać element w regularnych odstępach czasu, aż upłynie limit lub element zostanie znaleziony. Sprawdza się szczególnie przy elementach, których załadowanie czasem trwa dłużej niż zwykle, co jest częste w aplikacjach opartych na Ajax i JavaScript.

Wait wait = new FluentWait(driver)
.withTimeout(15, TimeUnit.SECONDS)
.pollingEvery(3, TimeUnit.SECONDS);

Powyższy kod ustawia limit czasu na 15 sekund oraz częstotliwość odpytywania na 3 sekundy. WebDriver poczeka maksymalnie 15 sekund i jeśli warunek zostanie spełniony, wykona kolejny krok. W przeciwnym razie zgłosi wyjątek. Skoro odpytywanie ustawiono na 3 sekundy, warunek zostanie sprawdzony dokładnie pięć razy.

Implicit Wait vs Explicit Wait, kluczowe różnice

Najłatwiej zrozumieć oba mechanizmy przez bezpośrednie zestawienie. Poniższa tabela porządkuje najważniejsze różnice.

Micro-takeaway: Implicit Wait czeka na ślepo i globalnie, a Explicit Wait czeka mądrze i punktowo, na konkretny warunek.

Co zatem wybrać

Znasz już mocne i słabe strony obu mechanizmów, więc wniosek nasuwa się sam. W większości projektów lepiej sięgać po bardziej elastyczny Explicit Wait, który nie marnuje czasu na sztuczne wstrzymywanie skryptów i sprawdza się przy zmiennych czasach ładowania.

Czy to jedyny słuszny wybór? Niekoniecznie. Przy bardzo małych projektach pisanych na szybko Implicit Wait bywa rozsądny, bo jego implementacja jest błyskawiczna, a sztuczne wydłużenie testów pozostaje znikome. Kluczowa jest jedna zasada: nie mieszaj obu mechanizmów w jednym projekcie, bo ich łączenie potrafi dawać nieprzewidywalne, sumujące się czasy oczekiwania i jeszcze bardziej rozchwiać testy. Decyzję o przyjętej strategii waitów warto opisać w planie testów, by cały zespół trzymał się jednej konwencji.

Jak ograniczyć flaky testy w praktyce

Stabilna automatyzacja to przede wszystkim konsekwentna praca z synchronizacją. Oto praktyczne wskazówki, które realnie skracają czas utrzymania i ograniczają losowe faile w CI.

• Postaw na Explicit Wait jako domyślny. Czekaj na konkretne warunki zamiast na sztywny upływ czasu.

• Nie łącz Implicit i Explicit Wait. Mieszanie obu mechanizmów prowadzi do nieprzewidywalnych czasów oczekiwania.

• Dobieraj warunek do akcji. Użyj elementToBeClickable() przed kliknięciem, a visibilityOfElementLocated() przed odczytem.

• Unikaj sztywnego sleep. Twarde wstrzymanie wątku marnuje czas i nie reaguje na realny stan strony.

• Stosuj Fluent Wait dla trudnych elementów. Tam, gdzie ładowanie bywa kapryśne, kontroluj częstotliwość odpytywania.

Micro-takeaway: większość flaky testów znika, gdy przestajesz zgadywać czas, a zaczynasz czekać na konkretny, sprawdzalny warunek. Dobór waitów to też element szerszego warsztatu, który opisujemy w przeglądzie narzędzi wspomagających testowanie oprogramowania, a samo miejsce automatyzacji w procesie tłumaczy materiał o testowaniu manualnym i automatycznym.

Podsumowanie i następny krok

Waity w Selenium WebDriver istnieją po to, by zsynchronizować skrypt z aplikacją, która ładuje elementy w różnym czasie. Implicit Wait jest prosty i szybki, ale globalny i sztucznie wydłuża testy. Explicit Wait jest inteligentny i dynamiczny, bo czeka na konkretny warunek. Fluent Wait dokłada do tego kontrolę nad częstotliwością odpytywania i obsługą wyjątków. Największą stabilność zyskujesz, gdy świadomie wybierasz mechanizm pod sytuację, zamiast łączyć je przypadkowo.

Pamiętaj o zasadzie nadrzędnej: w niemal każdym projekcie domyślnym wyborem powinien być Explicit Wait, a Implicit Wait zostaw co najwyżej dla małych, szybkich zadań. Konsekwentna strategia waitów to jeden z najtańszych sposobów na ograniczenie flaky testów i skrócenie czasu utrzymania frameworka.

Chcesz, by Twoje testy w Selenium były stabilne i przestały sypać się przez kapryśne elementy? Zespół Quality Island pomoże dobrać strategię waitów, uporządkować framework i wdrożyć dobre praktyki, a w razie potrzeby wesprze Cię szerszą automatyzacją testów. Napisz do nas, a pokażemy, jak realnie skrócić czas utrzymania automatyzacji w Twoim środowisku.

FAQ: waity w Selenium WebDriver w pytaniach i odpowiedziach

Poniżej zebraliśmy pytania, które najczęściej słyszymy od inżynierów QA i automatyzujących walczących z niestabilnymi testami w Selenium. Odpowiadamy konkretnie, bez owijania w technologiczny żargon.

Dlaczego waity w Selenium są ważne?

Waity synchronizują skrypt z aplikacją, która ładuje elementy w różnym czasie. Podczas wykonywania testów na czas odpowiedzi wpływa wiele czynników, takich jak obciążenie sieci, siła zasięgu internetu czy nieoptymalne mechanizmy aplikacyjne. Bez mechanizmu oczekiwania skrypt próbuje kliknąć element, którego jeszcze nie ma na stronie, i wywala się, choć aplikacja działa poprawnie, tylko nieco wolniej. To właśnie źródło flaky testów, które podkopują zaufanie zespołu do całej automatyzacji.

Co robi klasa Wait?

Klasa Wait wchodzi w skład biblioteki Selenium WebDriver i jest jej integralną częścią. Mówiąc w uproszczeniu, jej metody wstrzymują na określony czas wykonywanie skryptu, zanim przejdzie on do kolejnych kroków. Dzięki temu dajesz elementowi czas na pojawienie się w modelu DOM i pełne wyrenderowanie, na przykład na załadowanie tysięcy wierszy do tabeli. To kluczowe, bo większość aplikacji korzysta z technologii Ajax oraz JavaScript, co potęguje sytuację, w której elementy mają różne czasy ładowania.

Co się dzieje, gdy element nie zostanie znaleziony?

Jeśli WebDriver nie zlokalizuje elementu na stronie, zgłosi wyjątek NoSuchElementException. Formalnie oznacza on, że poszukiwany element nie został odnaleziony w modelu DOM strony. Bardzo często problem nie polega jednak na tym, że elementu nie ma, lecz że jest on jeszcze w trakcie ładowania lub renderowania. To właśnie ten scenariusz mają rozwiązywać waity, czyli Implicit Wait, Explicit Wait oraz Fluent Wait.

Czym jest Implicit Wait?

Implicit Wait, czyli oczekiwanie niejawne, to globalny timeout, który zadziała wtedy, gdy poszukiwany element nie jest widoczny od razu. WebDriver poczeka zdefiniowaną jednostkę czasu, a po jej przekroczeniu zgłosi wyjątek NoSuchElementException. Największą zaletą jest szybkość i prostota implementacji, bo wystarczy jedna linijka kodu. Wadą jest to, że sztucznie wydłuża czas testów oraz działa prawidłowo tylko z metodą findElement, co w wielu sytuacjach okazuje się niewystarczające.

Czym jest Explicit Wait?

Explicit Wait, czyli oczekiwanie jawne, pozwala zdefiniować konkretny warunek wznowienia działania kodu. Tworzysz obiekt klasy WebDriverWait, przekazujesz mu WebDrivera i wartość timeoutu, a następnie wywołujesz metodę until ze wskazanym warunkiem. Działa dynamicznie, więc jeśli element pojawi się w 5 sekund, oczekiwanie potrwa dokładnie 5 sekund, a nie cały zadeklarowany czas. Do pracy wykorzystujesz klasy WebDriverWait oraz ExpectedConditions, która oferuje zbiór gotowych warunków, na przykład visibilityOfElementLocated czy elementToBeClickable.

Czym jest Fluent Wait?

Fluent Wait, czyli płynne oczekiwanie, jest podobny do Explicit Wait, ale daje większą kontrolę. Poza maksymalnym czasem oczekiwania definiujesz też częstotliwość sprawdzania warunku oraz typy wyjątków, które mają być ignorowane podczas wyszukiwania. Mechanizm może wielokrotnie odpytywać element w regularnych odstępach czasu, aż upłynie limit lub element zostanie znaleziony. Sprawdza się szczególnie przy elementach, których załadowanie czasem trwa dłużej niż zwykle, co jest częste w aplikacjach opartych na Ajax i JavaScript.

Który mechanizm jest zwykle lepszy?

W większości projektów lepiej sięgać po Explicit Wait, bo nie marnuje czasu na sztuczne wstrzymywanie skryptów i sprawdza się przy zmiennych czasach ładowania. Czeka mądrze i punktowo, na konkretny warunek, zamiast czekać na ślepo i globalnie. Kluczowa jest jedna zasada: nie mieszaj Implicit i Explicit Wait w jednym projekcie, bo ich łączenie daje nieprzewidywalne, sumujące się czasy oczekiwania i jeszcze bardziej rozchwiewa testy.

Czy Implicit Wait nadal ma sens?

Tak, choć w ograniczonym zakresie. Przy bardzo małych projektach pisanych na szybko Implicit Wait bywa rozsądnym wyborem, bo jego implementacja jest błyskawiczna, a sztuczne wydłużenie testów pozostaje znikome. W większych i długoterminowych projektach lepiej go jednak ograniczyć lub wręcz wyeliminować na rzecz Explicit Wait. Najlepiej z góry ustalić jedną, spójną strategię waitów dla całego zespołu, by uniknąć przypadkowego mieszania mechanizmów.