Selenium 4 - Czy Twoje testy są gotowe na rewolucję?

W automatyzacji testów liczy się dziś nie tylko to, czy skrypt steruje przeglądarką, ale też jak łatwo da się go utrzymać, uruchamiać równolegle i diagnozować, gdy coś zaczyna się psuć. Selenium 4 porządkuje właśnie te obszary: upraszcza konfigurację driverów, daje wygodniejsze sposoby opisywania elementów, otwiera drogę do lepszej obserwowalności i opiera Grid na architekturze gotowej na kontenery oraz chmurę. Poniżej pokazuję, co z tych zmian jest naprawdę praktyczne, a co warto wdrażać z rozwagą.

Co zmieniło się w nowszej gałęzi frameworka i dlaczego to ważne

Na dziś stabilna wersja to 4.44.0 z 12 maja 2026, więc mówimy już nie o eksperymencie, ale o dojrzałej linii rozwojowej. Największa różnica względem starszych podejść polega nie na jednym efektownym dodatku, tylko na przesunięciu ciężaru z ręcznej konfiguracji na elementy wbudowane w ekosystem. W praktyce ja patrzę na cztery warstwy: lokatory, komunikację z przeglądarką, zarządzanie driverami i Grid.

To nie jest kosmetyczna aktualizacja. To raczej próba uporządkowania całego łańcucha pracy tak, aby zespół spędzał mniej czasu na gaszeniu problemów infrastrukturalnych, a więcej na jakości testów. Właśnie dlatego pierwszym praktycznym pytaniem nie powinno być „co nowego w API”, tylko „czy moje testy w ogóle są dziś napisane tak, żeby skorzystać z tych zmian”. I tu najczęściej zaczynam od locatorów.

Jak działają relative locators i kiedy naprawdę pomagają

Relative locators są przydatne wtedy, gdy element trudno opisać po atrybutach, ale łatwo wskazać go przez położenie względem innego elementu. To szczególnie wygodne w formularzach, panelach administracyjnych i gęstych dashboardach, gdzie układ jest czytelny dla człowieka, ale klasyczny selektor bywa sztuczny albo zbyt długi. W praktyce używam ich tam, gdzie relacja „nad”, „pod”, „obok” albo „blisko” jest stabilniejsza niż pełna ścieżka po DOM.

Kiedy mają sens

• W formularzach, gdzie etykieta i pole są blisko siebie, ale identyfikatory bywają niestabilne.
• W interfejsach panelowych, gdzie ten sam komponent występuje wiele razy, ale zawsze w tym samym układzie.
• W testach regresyjnych, w których chcesz ograniczyć zależność od długich XPathów.
• W sytuacjach, gdy czytelność testu jest ważniejsza niż absolutnie najkrótszy selektor.

Przeczytaj również: Odświeżanie strony w Selenium - Jak uniknąć błędów?

Kiedy lepiej zostać przy CSS lub XPath

• Gdy interfejs mocno reaguje na breakpointy i układ elementów zmienia się wraz z szerokością okna.
• Gdy elementy mają wielowierszowe treści, bo pozycjonowanie na podstawie prostokątów bywa wtedy mniej intuicyjne.
• Gdy relacja przestrzenna jest przypadkowa, a nie wynika z logiki interfejsu.
• Gdy masz stabilny i prosty atrybut `data-testid` lub sensowny identyfikator, bo wtedy klasyczny selektor nadal wygrywa prostotą.

Warto też pamiętać, że relative locators bazują na układzie widocznym na stronie, więc ich skuteczność zależy od layoutu, a nie tylko od struktury DOM. To bardzo praktyczne narzędzie, ale nie magia: dobrze działa tam, gdzie projekt interfejsu jest przewidywalny. Kiedy selektory są pod kontrolą, zaczyna mieć znaczenie to, co dzieje się w przeglądarce pod spodem, a to prowadzi wprost do BiDi.

WebDriver BiDi daje więcej wglądu w to, co robi przeglądarka

Jeżeli wcześniejsze wersje frameworka były głównie o sterowaniu przeglądarką, to BiDi przesuwa ciężar w stronę dialogu z nią. Chodzi o standard W3C, który ma zapewnić bardziej przewidywalny, wielobrowserowy sposób pracy z takimi obszarami jak logi, sieć, skrypty, kontekst przeglądania i zdarzenia wejścia. Dla testów automatycznych to ważne, bo sama informacja „element nie został znaleziony” często nie wystarcza do diagnozy problemu.

Selenium Manager usuwa największy ból początku wdrożenia

To jeden z tych komponentów, które nie robią spektakularnego wrażenia w prezentacji, ale potrafią oszczędzić wiele godzin frustracji. Selenium Manager to oficjalny manager driverów dołączany od wersji 4.6, działający jako fallback, gdy nie podasz drivera ręcznie. W praktyce ogranicza ręczne pobieranie `chromedrivera`, `geckodrivera` czy `msedgedrivera`, a więc eliminuje część problemów z PATH, niezgodnymi wersjami i środowiskami, które na różnych komputerach zachowują się inaczej.

Najlepiej sprawdza się w trzech sytuacjach: na nowym środowisku deweloperskim, w CI oraz wtedy, gdy wersje przeglądarek zmieniają się częściej niż sam kod testów. To nadal nie znaczy, że ręczne zarządzanie driverami przestało mieć sens. W środowiskach mocno kontrolowanych, z wymaganiami compliance albo bardzo precyzyjnym pinningiem wersji, jawna konfiguracja nadal bywa rozsądna.

Jest tu jednak jeden ważny haczyk: to wciąż komponent beta, więc warto zweryfikować go na swojej platformie, zanim oprzesz na nim cały pipeline. Oficjalna dokumentacja ostrzega też, że na części architektur Linuksa, w tym arm64/aarch64 i Raspberry Pi, wsparcie jest ograniczone. Jeśli więc pracujesz na nietypowym sprzęcie, lepiej sprawdzić to wcześniej niż po pierwszym nieudanym buildzie. Kiedy pojedyncza maszyna przestaje wystarczać, naturalnym kolejnym krokiem jest Grid.

Grid 4 jest zbudowany pod równoległe testy i skalowanie

Grid 4 to nie lekkie odświeżenie starej architektury, tylko przebudowa od podstaw. W praktyce oznacza to rozdzielenie odpowiedzialności między kilka komponentów, które razem obsługują routing żądań, kolejkę nowych sesji, dystrybucję, mapowanie sesji i samą pracę node’ów. Dla zespołu testowego przekłada się to na łatwiejsze uruchamianie dużych zestawów testów równolegle, lepszą obsługę różnych wersji przeglądarek i prostsze dopasowanie do kontenerów oraz infrastruktury chmurowej.

• Router przyjmuje ruch z zewnątrz i przekazuje go dalej do właściwego komponentu.
• New Session Queue trzyma żądania nowych sesji do momentu przydzielenia ich do node’a.
• Distributor decyduje, gdzie najlepiej uruchomić kolejną sesję.
• Node wykonuje samą sesję WebDriver.
• Session Map pamięta, na którym node’zie działa konkretna sesja.
• Event Bus przenosi komunikację między komponentami asynchronicznie.

W 2026 widać też mocniejszy nacisk na dynamiczne środowiska. W wydaniu 4.41 doszło natywne wsparcie dynamicznego Grid w Kubernetes, API zdarzeń sesji oraz lepsze, zdarzeniowe nagrywanie w obrazach kontenerowych. To ważne, bo pokazuje kierunek rozwoju: mniej statycznych, ręcznie utrzymywanych slotów, a więcej elastycznej infrastruktury, która skaluje się wraz z obciążeniem. Jednocześnie nie warto zaczynać od Grid, jeśli lokalne testy są niestabilne, bo sama infrastruktura nie naprawi źle zaprojektowanych scenariuszy. Najpierw warto uporządkować wdrożenie w zespole.

Jak wdrożyłbym to w zespole testowym bez niepotrzebnego ryzyka

Gdybym miał przeprowadzić migrację w praktycznym zespole QA, zrobiłbym to etapami, a nie jednorazowym „big bangiem”. Najpierw podniósłbym bindingi do spójnej wersji i zamroził ją w całym repozytorium, żeby uniknąć chaosu między modułami. Dopiero potem przechodziłbym przez kolejne warstwy frameworka, bo każda z nich rozwiązuje inny problem i każda może ujawnić inne słabości w testach.

1. Ustaliłbym jedną wersję bibliotek i driverów dla całego projektu, zamiast mieszać stare i nowe mechanizmy.
2. Przeniósłbym konfigurację sterowników na Selenium Manager tam, gdzie nie ma silnych powodów, by robić to ręcznie.
3. Przejrzałbym najbardziej kruche selektory i wymienił je na prostsze, a relative locators stosował tylko tam, gdzie układ UI jest naprawdę przewidywalny.
4. Włączyłbym BiDi najpierw w testach diagnostycznych, regresyjnych i tam, gdzie potrzebny jest wgląd w logi lub ruch sieciowy.
5. Grid uruchamiałbym dopiero wtedy, gdy lokalny suite jest w miarę stabilny, bo równoległość tylko przyspiesza to, co już istnieje.
6. Mierzyłbym trzy rzeczy: czas setupu, czas całego suite’u i liczbę flaky testów po aktualizacji.

Najczęstszy błąd, który widzę, to próba wykorzystania wszystkich nowych możliwości naraz. To zwykle kończy się tym, że zespół nie wie, co faktycznie poprawiło wynik, a co wprowadziło dodatkowy szum. Lepiej wdrożyć mniej, ale świadomie. Po takim uporządkowaniu zostaje już tylko kilka rzeczy do sprawdzenia przed zamknięciem migracji.

Na co zwrócić uwagę, zanim uznasz migrację za zakończoną

• Jeśli pracujesz w .NET, pamiętaj, że od 4.44 główne paczki są podpisane mocno, a osobne paczki StrongNamed zostały wycofane.
• Jeśli uruchamiasz testy na mniej typowej architekturze Linuksa, sprawdź zgodność Selenium Manager wcześniej, bo nie każde środowisko jest wspierane tak samo dobrze.
• Jeżeli suite opiera się na specyficznych komendach CDP, zostaw ścieżkę awaryjną i nie zakładaj, że BiDi zastępuje wszystko od razu.
• Po aktualizacji uruchom pełny przebieg z logami i metrykami, bo dopiero wtedy widać, czy zmiana naprawdę poprawiła stabilność.

Największy zwrot daje nie pojedyncza funkcja, ale uporządkowanie całego łańcucha pracy: lepsze lokatory, mniej ręcznego setupu, bardziej czytelna komunikacja z przeglądarką i Grid gotowy na równoległość. Jeśli patrzeć na to pragmatycznie, nowsza gałąź frameworka nie tylko przyspiesza testy, ale też obniża koszt ich utrzymania, a to w zespole QA zwykle robi największą różnicę.