Selenium czy Playwright? To pytanie słyszę za każdym razem, gdy zespół zaczyna myśleć o automatyzacji testów E2E. Oba narzędzia sterują prawdziwą przeglądarką i sprawdzają aplikację tak, jak robi to użytkownik: klik, formularz, przejście między ekranami. Różnią się jednak wiekiem, architekturą i tym, ile czasu tracisz na walkę z samym frameworkiem zamiast na pisanie testów. W tym wpisie porównuję je konkretnie i podpowiadam, co wybrać w zależności od Twojego kontekstu, bez fanatyzmu w żadną stronę.
Selenium i Playwright w dwóch akapitach
Selenium to weteran. Istnieje od kilkunastu lat, jest branżowym standardem i działa przez protokół WebDriver (dziś oficjalny standard W3C). Ma ogromną społeczność, wsparcie dla praktycznie każdego języka i przeglądarki oraz mnóstwo gotowych rozwiązań na Stack Overflow. Ceną tej dojrzałości jest starsza architektura: sterowanie przeglądarką idzie przez zewnętrzny driver, a o synchronizację, czekanie na elementy, w dużej mierze musisz zadbać sam.
Playwright to nowszy framework od Microsoftu, zaprojektowany z myślą o problemach, które w Selenium bolą najbardziej. Komunikuje się z przeglądarkami bezpośrednio przez ich protokoły debugowania (w Chromium jest to CDP), bez osobnego drivera po drodze. Ma wbudowane auto-czekanie, izolację kontekstów przeglądarki i świetne narzędzia do debugowania. W praktyce testy w Playwright są zwykle stabilniejsze i rzadziej „migają”, czyli nie padają losowo bez zmiany w aplikacji.
Selenium czy Playwright: porównanie po kluczowych kryteriach
- Języki. Selenium oficjalnie wspiera Javę, Pythona, C#, JavaScript i Ruby. To atut, jeśli zespół jest przywiązany do konkretnego stacku. Playwright ma oficjalne wsparcie dla TypeScript/JavaScript, Pythona, Javy i .NET (C#). Oba pokryją większość realnych potrzeb.
- Auto-wait. Tu Playwright wyraźnie wygrywa. Zanim kliknie, sam sprawdza, czy element jest widoczny, stabilny i gotowy na akcję. W Selenium standardem są jawne waits, a ich brak to najczęstsze źródło niestabilnych testów, jakie widzę u klientów.
- Szybkość. Playwright wykonuje akcje z mniejszym narzutem, bo nie przechodzi przez warstwę WebDrivera. Przy dużych zestawach testów różnica w czasie przebiegu potrafi być odczuwalna.
- Równoległość. Playwright, wraz ze swoim runnerem testowym, daje zrównoleglenie i izolację w standardzie: każdy test dostaje czysty kontekst przeglądarki. W Selenium podobny efekt osiągasz, dokładając Selenium Grid albo runner w rodzaju TestNG czy pytest-xdist.
- Przeglądarki. Selenium steruje realnymi przeglądarkami użytkowników (Chrome, Firefox, Edge, Safari) i pokrywa też mniej typowe konfiguracje. Playwright obsługuje Chromium, Firefoksa i WebKit (silnik Safari) na własnych binariach, czyli wszystkie liczące się silniki, ale nie „prawdziwe” Safari.
- Ekosystem. Selenium ma przewagę wieku: więcej integracji i gotowych odpowiedzi na problemy. Playwright nadrabia szybko i sporo daje „z pudełka”: trace viewer, nagrywanie testów (codegen), raport HTML, przechwytywanie ruchu sieciowego.
| Kryterium | Selenium | Playwright |
|---|---|---|
| Języki | Java, Python, C#, JS, Ruby | TS/JS, Python, Java, .NET (C#) |
| Auto-wait | Głównie ręczne waits | Wbudowane, domyślnie |
| Szybkość | Narzut warstwy WebDrivera | Mniejszy narzut, bez drivera |
| Równoległość | Grid / runner (dokładasz sam) | W standardzie, izolowane konteksty |
| Przeglądarki | Realne przeglądarki, najszersze pokrycie | Chromium, Firefox, WebKit |
| Próg wejścia | Wyższy, waits i grid ogarniasz sam | Niższy, dużo „z pudełka” |
Co wybrać do nowego projektu, a co do legacy
Nowy projekt: zwykle Playwright
Jeśli zaczynasz automatyzację E2E od zera i nie masz silnego przywiązania do konkretnego języka, w większości przypadków rekomenduję Playwright. Niższy próg wejścia, wbudowane auto-wait i równoległość oraz trace viewer sprawiają, że szybciej dostajesz stabilny, użyteczny zestaw testów. Mniej czasu schodzi na infrastrukturę i „latające” testy, więcej na realne pokrycie ścieżek biznesowych.
Legacy i istniejące testy: Selenium bywa lepszym wyborem
Jeśli masz już duży, działający zestaw testów w Selenium, zespół, który zna go na wylot, i pipeline dopięty pod WebDrivera, przepisywanie wszystkiego na Playwright rzadko się opłaca. Sama wygoda nowszego narzędzia nie uzasadnia kosztu migracji setek testów. Selenium wskażę też wtedy, gdy wymagane jest testowanie na realnym Safari lub nietypowych przeglądarkach spoza trójki Chromium/Firefox/WebKit, albo gdy cała otoczka zespołu (biblioteki, know-how, CI) jest zbudowana wokół WebDrivera.
Zespół i kontekst ważą więcej niż sam framework
O sukcesie automatyzacji decyduje nie logo frameworka, tylko to, kto i jak z niego korzysta. Zanim rozstrzygniesz dylemat, odpowiedz sobie na kilka pytań:
- W jakim języku pisze Twój zespół na co dzień? Trzymanie testów w tym samym stacku obniża próg wejścia i ułatwia utrzymanie.
- Masz już testy do utrzymania czy startujesz na czysto? To najważniejszy pojedynczy czynnik.
- Co dokładnie ma być zautomatyzowane i czy w ogóle to się opłaca? Zanim zaczniesz kodować testy E2E, warto rozstrzygnąć, które testy robić manualnie, a które automatyzować.
- Jak testy trafią do CI/CD? Niezależnie od frameworka wartość pojawia się dopiero, gdy testy uruchamiają się automatycznie, zobacz, jak wpiąć testy automatyczne w pipeline.
Dobrze zaprojektowane testy zaczynają się zresztą nie od kodu, tylko od tego, co mają sprawdzać, a to sprowadza się do porządnych przypadków testowych. Framework tylko wykonuje to, co wcześniej dobrze przemyślisz.
Jak pomagam w tym jako QA Sensei
Od 20 lat pracuję w IT, od siedmiu zajmuję się jakością oprogramowania i automatyzacją, więc doradzam pragmatycznie, a nie modowo. Pomagam wybrać framework pod realny kontekst zespołu, postawić stabilny szkielet testów E2E, w Selenium albo Playwright, zależnie od tego, co ma sens u Ciebie, wpiąć je w CI/CD i wyeliminować „latające” testy, które podkopują zaufanie do automatyzacji. Tam, gdzie faktycznie skraca to pracę, dokładam automatyzację procesów i wsparcie AI. Zobacz zakres usług i jak wygląda współpraca, pracuję zdalnie w całej Polsce, ewentualnie u klienta w okolicach Wrocławia.