Najważniejsze rzeczy o odświeżaniu strony w Selenium
- Najbezpieczniejszym domyślnym wyborem jest metoda odświeżenia z obiektu nawigacji, np. `navigate().refresh()`.
- Po przeładowaniu strony stare referencje do elementów często stają się nieaktualne, więc trzeba je wyszukać ponownie.
- Samo odświeżenie nie zastępuje poprawnego oczekiwania na stan aplikacji; zwykle potrzebny jest explicit wait.
- Jeśli test ma być stabilny, lepiej zaczynać go z czystego stanu niż ratować się wieloma refreshami.
- W niektórych przypadkach sens ma ponowne wejście na ten sam adres lub reload przez JavaScript, ale to powinien być wariant pomocniczy, nie pierwszy odruch.
Co naprawdę robi odświeżenie strony w Selenium
W Selenium odświeżenie oznacza ponowne załadowanie bieżącej strony w tej samej karcie. W praktyce selenium refresh page sprowadza się do odwołania, które uruchamia standardową akcję przeglądarki, a nie do żadnego „resetu” aplikacji. To ważne rozróżnienie, bo odświeżenie nie czyści sesji, nie naprawia błędnego stanu testu i nie gwarantuje, że wszystkie komponenty zdążyły już zbudować swój widok.
Oficjalna dokumentacja Selenium pokazuje, że komendy nawigacyjne czekają na określony stan ładowania strony, domyślnie `readyState = complete`, ale to nie znaczy, że aplikacja oparta mocno o JavaScript jest już faktycznie gotowa do interakcji. Jeśli po stronie klienta dane dochodzą jeszcze chwilę po zakończeniu ładowania, sam powrót z komendy odświeżenia nie wystarczy. Ja traktuję ten moment jako początek kolejnego etapu testu, a nie jego koniec.
To prowadzi do praktycznej zasady: najpierw wybieram sposób przeładowania, a dopiero potem definiuję warunek, po którym test uznam za gotowy do kolejnego kroku. Bez tego odświeżenie staje się tylko ruchem kosmetycznym.
Najprostsze metody odświeżenia bieżącej strony
Jeśli chodzi o samą technikę, w większości przypadków zaczynam od natywnej komendy przeglądarki. Jest najczytelniejsza, najlepiej komunikuje intencję i najmniej zaskakuje osobę, która później czyta test.
| Metoda | Przykład | Kiedy używać | Na co uważać |
|---|---|---|---|
| Natywne odświeżenie | driver.navigate().refresh() |
Gdy chcesz odświeżyć bieżącą stronę tak, jak zrobiłby to użytkownik | Po reloadzie stare elementy mogą stracić ważność |
| Wczytanie bieżącego URL | driver.get(driver.getCurrentUrl()) |
Gdy helper pracuje na adresach URL i chcesz wymusić nowe wejście na ten sam adres | To nie zawsze jest semantycznie to samo co kliknięcie odświeżania w przeglądarce |
| Reload przez JavaScript | executeScript("window.location.reload()") |
Jako wariant awaryjny albo wtedy, gdy potrzebujesz większej kontroli nad kontekstem skryptu | Po takim reloadzie nadal musisz sam zadbać o oczekiwanie na stan aplikacji |
Przeczytaj również: Fixture w testach - jak stabilizować automatyzację?
Składnia w popularnych językach
-
Java:
driver.navigate().refresh(); -
Python:
driver.refresh() -
JavaScript:
await driver.navigate().refresh(); -
C#:
driver.Navigate().Refresh(); -
Ruby:
driver.navigate.refresh
Ja zwykle zaczynam od native refresh, bo jest najbardziej jednoznaczny. Dopiero jeśli mam specyficzny helper oparty na URL-ach albo problematyczny przypadek z aplikacją, schodzę do alternatywy.
W dokumentacji Selenium widać też wyraźnie, że refresh jest częścią nawigacji przeglądarki, a nie osobnym „trikiem” testowym. To dobra wskazówka: im bliżej zachowania realnego użytkownika, tym łatwiej później zrozumieć wyniki testu.
Kiedy refresh wygrywa z ponownym wejściem na adres
Refresh i ponowne wejście na ten sam URL wyglądają podobnie, ale w testach nie są wymienne w stu procentach. Ja rozdzielam je według intencji, a nie według przyzwyczajenia.
| Sytuacja | Lepszy wybór | Dlaczego |
|---|---|---|
| Chcę odświeżyć dashboard po aktualizacji danych | refresh() |
To najbliższe temu, co zrobiłby użytkownik, i najlepiej pasuje do weryfikacji widoku po pollingowej aktualizacji |
| Helper testowy operuje wyłącznie na URL-ach | get(current_url) |
Gdy kod już zarządza adresami, ponowne wejście na ten sam URL bywa czytelniejsze niż mieszanie kilku obiektów nawigacji |
| Trzeba awaryjnie wymusić reload w trudnym środowisku | JavaScript reload | To dobry wariant pomocniczy, ale nie powinien być domyślną odpowiedzią na każdy problem |
Warto też pamiętać o ograniczeniach. Na stronach z formularzem wysyłanym metodą POST odświeżenie może uruchomić komunikat o ponownym wysłaniu danych albo zmienić stan aplikacji w sposób, którego nie planowałeś. W aplikacjach z ciężkim frontem i wieloma stanami po stronie klienta lepiej najpierw sprawdzić, czy naprawdę potrzebujesz reloadu, czy raczej nowego wejścia do scenariusza.
Jeśli test dotyka autoryzacji, cookies albo lokalnego stanu przeglądarki, ani refresh, ani ponowne wejście na URL nie dają „czystej kartki”. Wtedy trzeba rozwiązać problem u źródła, a nie mnożyć odświeżenia.
Jak uniknąć błędów po przeładowaniu
Najczęstszy problem po reloadzie to stale element reference. Dokumentacja Selenium wprost pokazuje, że po odświeżeniu strony albo zmianie DOM referencja do elementu może przestać być ważna, więc trzeba go odszukać ponownie. To jeden z tych błędów, które początkujący często interpretują jako „Selenium nie działa”, choć w praktyce problem leży w cyklu życia elementu.
Ja stosuję trzy zasady: nie trzymam `WebElement` przez refresh, po reloadzie wyszukuję element jeszcze raz i czekam na konkretny sygnał gotowości, a nie na sam fakt zakończenia nawigacji.
By status = By.cssSelector("[data-test='status']");
driver.navigate().refresh();
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(d -> d.findElement(status).isDisplayed());To jest bezpieczniejsze niż ślepe `Thread.sleep`, bo opiera się na warunku, który naprawdę ma znaczenie dla testu. Jeśli potrzebujesz innego sygnału, możesz czekać na tekst, URL, tytuł albo zniknięcie elementu ładowania. W aplikacjach dynamicznych samo `readyState = complete` bywa za słabe, bo JavaScript potrafi jeszcze przez chwilę dogrywać treść i zmieniać DOM po stronie klienta.
Praktycznie rzecz biorąc, im bardziej selektywnie czekasz, tym mniej flakiness przenosi się na cały suite. To zwykle daje większy efekt niż kolejne próby „naprawiania” testu po odświeżeniu.
Nie traktuj odświeżania jako naprawy złego stanu testu
Refresh bywa kuszącym skrótem, ale nie powinien zastępować porządnego przygotowania testu. Selenium zaleca zaczynanie każdego scenariusza od znanego, czystego stanu, a jeśli to możliwe, od osobnego WebDrivera dla każdego testu. To nie jest detal organizacyjny, tylko fundament stabilności.
W praktyce odświeżenie nie rozwiązuje takich rzeczy jak:
- zanieczyszczone cookies lub `localStorage`,
- stan sesji przenoszony między testami,
- dane przygotowane ręcznie zamiast przez API lub fixture,
- zależność jednego testu od wyniku innego testu,
- ukryte opóźnienia w aplikacji, które refresh tylko maskuje.
Ja zwykle patrzę na częste odświeżanie jak na objaw, a nie rozwiązanie. Jeśli test wymaga kilku reloadów, żeby przejść, to najczęściej problem leży w przygotowaniu danych, synchronizacji albo w samej architekturze scenariusza. Dokumentacja Selenium zresztą zachęca, by nie używać przeglądarki do przygotowywania wszystkiego od zera, jeśli ten sam efekt da się osiągnąć szybciej przez API lub inny niż przeglądarka poziom testu.
To ważne szczególnie w dużych suite’ach, gdzie każde dodatkowe odświeżenie spowalnia wykonanie i zwiększa liczbę miejsc, w których coś może się rozjechać.
Co warto wdrożyć od razu w swoim helperze
Jeśli miałbym zamknąć cały temat w jednym nawyku, byłby to prosty helper: odśwież stronę, a potem poczekaj na konkretny, biznesowy warunek. Nie na sam fakt „strona się załadowała”, tylko na coś, co faktycznie potwierdza gotowość aplikacji do kolejnego kroku.
void refreshAndWait(WebDriver driver, By locator) {
driver.navigate().refresh();
new WebDriverWait(driver, Duration.ofSeconds(10))
.until(d -> d.findElement(locator).isDisplayed());
}W mojej praktyce najlepiej działają testy, które odświeżają stronę rzadko, celowo i zawsze z warunkiem końcowym. Jeśli musisz sięgać po reload często, warto najpierw poprawić setup, izolację danych i sposób oczekiwania na stan aplikacji. Wtedy odświeżanie przestaje być protezą, a staje się normalnym, przewidywalnym elementem scenariusza.
