W testach przeglądarkowych największe tarcie zwykle nie leży w samych asercjach, tylko w utrzymaniu zgodności między przeglądarką a plikiem drivera. Pakiet webdrivermanager rozwiązuje właśnie ten problem: pobiera właściwy sterownik, dopasowuje wersję i przygotowuje go tak, żeby Selenium mogło go uruchomić bez ręcznego grzebania w PATH. Dla zespołu oznacza to mniej awarii po aktualizacji Chrome czy Firefoksa, a dla CI mniej powtarzalnych błędów, które trudno diagnozować.
Najkrócej, to narzędzie automatyzuje najbardziej kłopotliwy fragment pracy z driverami
- pobiera i instaluje sterowniki przeglądarek używanych w automatyzacji testów,
- ogranicza ręczne zarządzanie plikami binarnymi i ścieżkami,
- pomaga utrzymać zgodność między wersją przeglądarki i drivera,
- najbardziej przydaje się w projektach legacy, CI, Dockerze i środowiskach z ograniczeniami sieciowymi,
- w nowych projektach Selenium 4.6+ często lepszym domyślnym wyborem jest Selenium Manager.
Czym jest i kiedy naprawdę się przydaje
To Pythonowy moduł do pobierania i instalowania driverów przeglądarek, tak aby Selenium nie musiało polegać na ręcznie wrzuconych binarkach. Według PyPI ostatnie wydanie tego pakietu pochodzi z 2021 roku i projekt ma status beta, więc w 2026 r. traktuję go raczej jako rozwiązanie dla istniejących projektów niż domyślny wybór do nowych wdrożeń.
Ma sens tam, gdzie zależy Ci na wyraźnej kontroli wersji drivera, gdzie pracujesz w starym kodzie Selenium albo gdzie musisz dostosować pobieranie do niestandardowego środowiska. W praktyce najlepiej sprawdza się w trzech scenariuszach: testach uruchamianych w CI, obrazach Docker i projektach, które dziedziczą po sobie różne wersje przeglądarek.
- ChromeDriver dla Chrome,
- GeckoDriver dla Firefoksa,
- EdgeDriver i EdgeChromiumDriver dla Microsoft Edge,
- OperaChromiumDriver dla Opery opartej o Chromium,
- IeDriver dla Internet Explorera, który dziś ma już głównie znaczenie utrzymaniowe.
Gdy utrzymuję testy, wolę takie narzędzie rozumieć jako warstwę pomocniczą, a nie fundament architektury. Z tego powodu najpierw warto zobaczyć, jak dokładnie biblioteka wybiera, pobiera i umieszcza driver na dysku.
Jak działa pobieranie, cache i dopasowanie wersji
Mechanizm jest prosty, ale ważne są szczegóły. Biblioteka sprawdza wersję przeglądarki, dobiera pasujący driver, pobiera archiwum, rozpakowuje binarkę i odkłada ją tam, gdzie Selenium lub inny runner będzie ją widział. Właśnie ten ciąg kroków eliminuje ręczne ściąganie plików i przypadkowe różnice między maszynami deweloperskimi.
- Wykrycie przeglądarki - narzędzie sprawdza, jaka wersja Chrome, Firefoksa albo Edge jest zainstalowana w systemie.
- Dobór drivera - na tej podstawie wybierana jest odpowiednia wersja sterownika.
- Pobranie i rozpakowanie - binarka trafia lokalnie, a archiwum jest rozpakowywane do katalogu roboczego albo cache.
- Umieszczenie w ścieżce dostępu - driver jest kopiowany lub linkowany do miejsca, które Selenium potrafi znaleźć bez dodatkowych sztuczek.
W starszym pakiecie można było dodatkowo wskazać katalog pobierania i katalog docelowy, a nawet wymusić wykrywanie systemu. To wygodne, jeśli uruchamiasz testy na wielu maszynach albo chcesz oddzielić cache od finalnej ścieżki binarki.
Przy driverach pobieranych z GitHuba pamiętam jeszcze o tokenie autoryzacyjnym, bo bez niego łatwo wpaść na limity zapytań. W sieci firmowej dochodzą proxy i certyfikaty SSL, więc takie narzędzie jest najbardziej użyteczne wtedy, gdy chcesz zamknąć całą logikę w kodzie lub w pipeline, a nie rozrzucać ją po instrukcjach dla ludzi.
Dopiero na tym tle widać, jak wdrożyć ten wzorzec sensownie w samym projekcie Selenium.
Jak wdrożyć to w praktyce w projekcie Selenium
W nowych projektach robię to inaczej: sam wzorzec zostaje ten sam, ale częściej używam Selenium Managera albo nowszej biblioteki z aktywniejszym ekosystemem. Jeśli jednak chcesz zobaczyć klasyczny układ z driverem zwracanym z managera, wygląda on tak:
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager
service = Service(ChromeDriverManager().install())
driver = webdriver.Chrome(service=service)Ten sam schemat działa dla Firefoksa i Edge'a, więc różni się tylko klasa managera. Dzięki temu logika testu pozostaje czysta: w teście sprawdzasz zachowanie aplikacji, a nie to, skąd wziął się plik wykonywalny. Dla mnie to ważna granica, bo im mniej kodu infrastrukturalnego w testach, tym łatwiej je utrzymać.
Jeżeli pracujesz na starszej bazie kodu, instalacja samego pakietu jest banalna:
pip install webdrivermanagerW praktyce sens tego kroku jest prosty: narzędzie ma przygotować driver, a Selenium ma już tylko wystartować sesję. Z tego miejsca naturalnie przechodzimy do pytania, czy w 2026 r. w ogóle warto sięgać po takie rozwiązanie, skoro Selenium ma własny mechanizm.
Kiedy lepiej wybrać inne rozwiązanie
Jak podaje dokumentacja Selenium, dla nowych projektów 4.6+ domyślnym wyborem jest Selenium Manager. Ja patrzę na to tak: jeśli nie mam mocnego powodu, żeby robić to inaczej, nie dokładam dodatkowej biblioteki tylko po to, żeby pobrać driver. Wyjątek robię wtedy, gdy potrzebuję pełniejszej kontroli albo utrzymuję starszy kod.
| Podejście | Kiedy ma sens | Plusy | Minusy |
|---|---|---|---|
| Ręczne pobieranie drivera | Jednorazowe laby i małe eksperymenty | Pełna kontrola nad plikiem | Najwięcej pracy i najwyższe ryzyko rozjazdu wersji |
| Selenium Manager | Nowe projekty Selenium 4.6+ | Brak dodatkowej zależności, działa automatycznie | Mniej elastyczny w bardzo niestandardowych środowiskach |
| Starsza biblioteka driver managera | Legacy, kontrola ścieżek, niestandardowe cache | Jasny przepływ pobierania i instalacji | Projekt jest stary i nie jest pierwszym wyborem do nowych wdrożeń |
Nowszy webdriver-manager
|
Gdy chcesz kontroli w Pythonie, ale z aktywniejszym ekosystemem | Wygodna konfiguracja i szerokie użycie | Dodatkowa zależność w projekcie |
Wybór zwykle sprowadza się do jednego pytania: czy chcesz maksymalnie uprościć projekt, czy jednak potrzebujesz precyzyjnej kontroli nad driverem, cache i sposobem pobierania. Gdy to ustalisz, znacznie łatwiej wyłapać błędy, które później psują uruchamianie testów. To właśnie one najczęściej decydują o tym, czy narzędzie pomaga, czy tylko dokłada kolejny punkt awarii.
Najczęstsze błędy, które robią z driver managera źródło problemów
- Zakładanie, że przeglądarka nie zaktualizuje się sama. Automatyczna aktualizacja Chrome lub Edge potrafi rozjechać wcześniej dobrany driver i wtedy pojawia się klasyczny błąd zgodności.
- Trzymanie binarek na sztywno w repozytorium albo w jednym lokalnym PATH. Działa na Twojej maszynie, ale psuje się na CI, Dockerze albo u kolegi z innego systemu.
- Brak polityki cache. Jeśli pipeline za każdym razem pobiera sterownik od nowa, testy startują wolniej i częściej łapią problemy sieciowe.
- Ignorowanie ograniczeń sieci firmowej. Proxy, certyfikaty SSL i limity zewnętrznych serwisów są częstym powodem "losowych" awarii, które wcale nie są losowe.
- Traktowanie takiej biblioteki jak rozwiązania uniwersalnego. To narzędzie do desktopowego automatyzowania przeglądarek, a nie zamiennik Appium czy frameworków mobilnych.
Najwięcej błędów nie wynika z samego kodu, tylko z tego, że proces przygotowania środowiska testowego jest rozpisany zbyt luźno. Im wcześniej go uporządkujesz, tym mniej czasu stracisz na diagnostykę. To prowadzi do ostatniej, praktycznej kwestii: jak ja bym to ułożył w 2026 r., żeby nie zamknąć sobie drogi rozwoju.
Jak ja bym to dziś ułożył w zespole testowym
Jeśli zaczynam nowy projekt, wybieram Selenium Manager i nie dokładam biblioteki tylko po to, żeby rozwiązać problem, który framework już umie załatwić sam. Jeśli utrzymuję legacy, wtedy świadomie zostawiam warstwę zarządzania driverami, ale pilnuję, żeby była odseparowana od logiki testowej. To daje prostszy kod, mniej kruchych zależności i łatwiejsze wdrażanie nowych osób do zespołu.
- trzymaj konfigurację driverów poza samymi testami,
- jednym sposobem obsłuż Chrome, Firefox i Edge,
- cache trzymaj blisko pipeline, jeśli uruchamiasz testy w CI,
- zapisz procedurę awaryjną dla środowisk z proxy lub ograniczonym dostępem do internetu.
Właśnie taki układ najbardziej się broni: mniej ręcznych wyjątków, mniej niespodzianek po aktualizacji przeglądarki i więcej czasu na faktyczne testowanie aplikacji, a nie utrzymywanie driverów.
