Selenium, Cypress czy Playwright: porównanie narzędzi do automatyzacji testów i kiedy które wybrać

Czas czytania: około 13 minut

Zespół wybiera narzędzie do automatyzacji testów webowych raz na kilka lat, a potem żyje z tą decyzją w każdym sprincie. Wybór po rankingu z bloga kończy się zwykle tak samo: Cypress w zespole, który testuje aplikację z płatnościami w osobnej domenie, Selenium w zespole frontendowym, który nie ma nikogo od Javy, albo Playwright wdrożony na siłę tam, gdzie osiemset testów w Selenium działa i nikt nie ma czasu ich przepisać. Trzy narzędzia rozwiązują ten sam problem trzema różnymi architekturami, i to architektura, nie moda, decyduje, które pasuje do Was.

W tym tekście porównujemy Selenium WebDriver, Cypress i Playwright w dwunastu kryteriach, wyjaśniamy, czym różni się ich architektura i dlaczego to ważne, opisujemy każde narzędzie osobno z jego mocnymi stronami i ograniczeniami, dajemy tabelę decyzyjną według sytuacji zespołu, pokazujemy ten sam test w trzech składniach, odpowiadamy na pytanie o migrację i wymieniamy błędy przy wyborze. Fakty o narzędziach bierzemy z ich dokumentacji, nie z rankingów, a z liczb podajemy tylko te, które da się sprawdzić.

Czym są Selenium WebDriver, Cypress i Playwright?

Wszystkie trzy to narzędzia do automatyzacji przeglądarek używane do testów aplikacji webowych: Selenium WebDriver istnieje od 2004 roku i stał się standardem W3C, Cypress powstał jako narzędzie dla developerów frontendowych z testami uruchamianymi wewnątrz przeglądarki, a Playwright to projekt Microsoftu, który łączy sterowanie wieloma przeglądarkami z automatycznym oczekiwaniem i śledzeniem wykonania.

Selenium opisujemy osobno w tekście Selenium: co to jest, jak działa i od czego zacząć, więc tutaj tylko przypomnienie: to biblioteka w wybranym języku, która przez sterownik producenta przeglądarki wysyła polecenia w protokole WebDriver. Cypress to framework w JavaScripcie, który uruchamia testy w tej samej pętli zdarzeń co aplikacja, dzięki czemu widzi wszystko, co dzieje się na stronie, i daje podgląd na żywo z możliwością cofania się w czasie. Playwright to biblioteka i framework testowy od Microsoftu, sterujące Chromium, Firefoksem i WebKitem jednym interfejsem, dostępne w TypeScripcie, Pythonie, .NET i Javie.

Czym różni się architektura trzech narzędzi?

Selenium działa z zewnątrz przez protokół i sterownik, Cypress działa wewnątrz przeglądarki obok testowanej aplikacji, a Playwright steruje przeglądarką bezpośrednio własnym protokołem przez trwałe połączenie; z tych trzech decyzji wynika prawie wszystko: szybkość, stabilność, obsługa wielu kart i domen oraz to, w jakim języku możecie pisać.

Ograniczenia Cypressa wynikające z architektury opisuje sama dokumentacja w sekcji Trade-offs: test działa w jednej naddomenie naraz (przejście do innej wymaga osobnego polecenia), obsługa ramek jest ograniczona, a wiele kart wymaga wtyczki. To nie są błędy, tylko cena za wygodę pracy wewnątrz przeglądarki. Automatyczne oczekiwanie Playwrighta opisuje sekcja Actionability: przed każdą akcją narzędzie sprawdza, czy element jest widoczny, stabilny, odsłonięty i gotowy, a asercje ponawiają się do skutku.

Selenium, Cypress i Playwright w dwunastu kryteriach

W dwunastu kryteriach Playwright wygrywa szybkością, oczekiwaniem, obsługą wielu kart i domen, narzędziami do debugowania i liczbą języków przy trzech silnikach przeglądarek; Selenium wygrywa liczbą języków, przeglądarek z Safari włącznie, dojrzałością i integracją z Appium; Cypress wygrywa wygodą dla developera frontendowego i testami komponentów.

Źródła: przeglądarki w Playwright, trace viewer, codegen, testy komponentów w Cypress, cennik Cypress Cloud, Selenium Grid. Liczby z blogów porównawczych typu „Playwright jest o 42 procent szybszy” pomijamy, bo zależą od zestawu, na którym je zmierzono, i nikt ich nie da się sprawdzić w Waszym projekcie bez własnego pilota.

Playwright: co to jest i dlaczego jest domyślnym wyborem dla nowych projektów?

Playwright to otwarta biblioteka i framework testowy od Microsoftu, sterujące Chromium, Firefoksem i WebKitem jednym interfejsem w TypeScripcie, Pythonie, Javie lub .NET; jest domyślnym wyborem dla nowych projektów, bo automatyczne oczekiwanie usuwa główne źródło niestabilności, a trace viewer skraca diagnozę padnięć do minut.

• Automatyczne oczekiwanie. Przed kliknięciem Playwright sprawdza, czy element jest w drzewie, widoczny, stabilny (nie animuje się), odsłonięty i włączony. Asercje typu „element ma tekst” ponawiają się do limitu czasu. Znika większość uśpień i ręcznych oczekiwań z Selenium.
• Trace viewer. Zapis wykonania testu z zrzutami przed i po każdej akcji, żądaniami sieciowymi, konsolą i kodem. Padnięcie w pipeline ogląda się jak film, bez odtwarzania lokalnie.
• Trzy silniki, jeden interfejs. Chromium, Firefox i WebKit (silnik Safari) instalowane przez samo narzędzie, bez sterowników. Test na WebKit na Linuksie sprawdza to, co użytkownik zobaczy na iPhonie, z zastrzeżeniem, że to silnik, nie Safari.
• Konteksty przeglądarki. Izolowane sesje w jednym procesie: dwóch użytkowników rozmawiających ze sobą w jednym teście, logowanie raz i ponowne użycie stanu w setkach testów.
• Codegen i inspektor. Nagrywanie kliknięć do kodu z sensownymi lokatorami (rola, tekst, etykieta), które da się potem poprawić ręcznie.
• Ograniczenia. Brak Safari jako przeglądarki (jest WebKit), brak aplikacji mobilnych natywnych, młodszy ekosystem wtyczek niż Selenium, mniej ogłoszeń o pracę w Polsce niż dla Selenium, choć rośnie.

Playwright uczymy w czterech językach na szkoleniach Automatyzacja testów z narzędziem Playwright, z osobnymi wariantami dla Pythona i Javy.

Cypress: co to jest i kiedy jego ograniczenia nie przeszkadzają?

Cypress to framework w JavaScripcie i TypeScripcie, w którym test działa wewnątrz przeglądarki obok aplikacji, z podglądem na żywo i cofaniem w czasie; jego ograniczenia (jedna domena naraz, ograniczone ramki i karty, brak Javy i Pythona) nie przeszkadzają zespołom frontendowym testującym własną aplikację jednostronicową i jej komponenty.

• Praca wewnątrz przeglądarki. Test ma dostęp do okna, dokumentu i sieci aplikacji bez pośredników. Automatyczne ponawianie poleceń i asercji, czytelne komunikaty, podgląd każdego kroku.
• Testy komponentów. Montowanie komponentu React, Vue albo Angular w prawdziwej przeglądarce i testowanie go w izolacji. Dla zespołów frontendowych to często ważniejsze niż testy end to end.
• Wygoda developera. Konfiguracja w kilka minut, wbudowane zrzuty i wideo, przechwytywanie żądań sieciowych i podstawianie odpowiedzi bez dodatkowych bibliotek.
• Ograniczenia architektury. Jedna naddomena w teście (zewnętrzna bramka płatności albo logowanie przez dostawcę tożsamości wymagają osobnego polecenia i ostrożności), ograniczone ramki, wiele kart przez wtyczkę, tylko JavaScript i TypeScript, Safari poza zasięgiem.
• Koszt równoległości. Równoległe uruchamianie i panel wyników są częścią płatnej usługi Cypress Cloud; własną równoległość da się zbudować, ale to praca, którą Playwright ma w standardzie.

Cypress ma sens wtedy, gdy testy piszą ci sami ludzie, którzy piszą front, i testują głównie własną aplikację. Uczymy go na szkoleniu Automatyzacja testów w Cypress, a razem z Playwrightem i Vitest na szkoleniu Testowanie aplikacji frontendowych.

Selenium: kiedy standard wygrywa z nowszymi narzędziami?

Selenium wygrywa wtedy, gdy zespół pisze w Javie, C#, Ruby albo Kotlinie, gdy testy muszą biegać na prawdziwym Safari, gdy ta sama ekipa automatyzuje aplikacje mobilne w Appium, gdy istnieje działający zestaw setek testów oraz gdy firma zatrudnia z rynku, na którym ogłoszenia nadal proszą o Selenium.

• Język zespołu. Java to nadal najczęstszy język zaplecza w polskich firmach i najczęstszy wymóg w ogłoszeniach dla testerów automatyzujących. Playwright ma Javę, ale ekosystem javowy wokół Selenium jest nieporównanie większy.
• Prawdziwe przeglądarki. Selenium steruje zainstalowanym Safari, Chrome, Firefoksem i Edge przez sterowniki ich producentów. Playwright testuje silniki, Cypress nie ma Safari.
• Appium. Automatyzacja aplikacji mobilnych w Appium używa tego samego protokołu i podobnego kodu. Jeden zespół, jeden warsztat na web i mobile. Szczegóły w tekście o narzędziach do automatyzacji testów mobilnych.
• Istniejący zestaw. Osiemset działających testów w Selenium to aktywa. Przepisanie ich na Playwright kosztuje miesiące i nie musi dać nic poza satysfakcją.
• Infrastruktura. Selenium Grid i wszystkie farmy przeglądarek w chmurze wspierają WebDriver od lat; nowsze narzędzia doganiają.
• Cena. Więcej kodu na oczekiwania, konfigurację i raporty. Zespół musi sam zbudować to, co Playwright ma w pudełku.

Liczby z projektu dla Argos, potwierdzone przez klienta. Podajemy je tu celowo: skrócenie regresji nie wzięło się ze zmiany narzędzia, tylko z przeniesienia logiki z testów interfejsu na API. Żadne z trzech narzędzi nie naprawi odwróconej piramidy testów.

Czy Selenium jest więc przestarzałe? Nie. Jest standardem W3C, rozwija się aktywnie w serii 4, ma największy ekosystem i najwięcej ogłoszeń o pracę. Jest wolniejsze i wymaga więcej kodu niż Playwright, ale dla zespołów javowych, testów na prawdziwym Safari i automatyzacji mobilnej w Appium pozostaje rozsądnym wyborem.

Kiedy wybrać które narzędzie: decyzja według sytuacji zespołu

Decyzję rozstrzyga sytuacja zespołu, nie ranking: nowy projekt bez ograniczeń językowych to Playwright, zespół javowy albo z Appium to Selenium, zespół frontendowy testujący własną aplikację i komponenty to Cypress, a istniejący działający zestaw zostaje w swoim narzędziu, dopóki nie zacznie kosztować więcej niż migracja.

Jeżeli po tabeli zostają dwa narzędzia, zróbcie tygodniowy pilot: pięć scenariuszy krytycznych w każdym, uruchomionych dziesięć razy z rzędu lokalnie i w pipeline. Wygrywa to, które ma mniej padnięć bez błędu w aplikacji i które zespół chce utrzymywać w środę o siedemnastej. Kiedy w ogóle automatyzować, rozkładamy w tekście o zaletach i wadach automatyzacji testów.

Jak wygląda ten sam test w trzech narzędziach?

Ten sam scenariusz logowania różni się w trzech narzędziach głównie tym, kto czeka na elementy: w Selenium pisze to tester, w Cypress i Playwright robi to narzędzie; różnica w długości kodu to różnica w liczbie miejsc, w których test może być niestabilny.

Selenium WebDriver, Python

driver.get("https://app.przyklad.pl/login")
WebDriverWait(driver, 10).until(EC.visibility_of_element_located((By.ID, "email"))).send_keys("tester@przyklad.pl")
driver.find_element(By.ID, "password").send_keys("Haslo123!")
driver.find_element(By.CSS_SELECTOR, "button[type='submit']").click()
WebDriverWait(driver, 10).until(EC.text_to_be_present_in_element((By.TAG_NAME, "h1"), "Twoje rezerwacje"))

Cypress, JavaScript

cy.visit("https://app.przyklad.pl/login")
cy.get("#email").type("tester@przyklad.pl")
cy.get("#password").type("Haslo123!")
cy.get("button[type='submit']").click()
cy.get("h1").should("contain", "Twoje rezerwacje")

Playwright, TypeScript

await page.goto("https://app.przyklad.pl/login");
await page.getByLabel("E-mail").fill("tester@przyklad.pl");
await page.getByLabel("Hasło").fill("Haslo123!");
await page.getByRole("button", { name: "Zaloguj" }).click();
await expect(page.getByRole("heading", { name: "Twoje rezerwacje" })).toBeVisible();

Trzy różnice do zapamiętania. Po pierwsze, w Selenium oczekiwanie jest jawne i pisane przez testera, w dwóch pozostałych wbudowane. Po drugie, Playwright zachęca do lokatorów po roli i etykiecie, czyli tak, jak stronę widzi użytkownik i czytnik ekranu, co czyni testy odporniejszymi na zmiany układu. Po trzecie, Cypress używa łańcucha poleceń bez await, co jest wygodne do czasu, aż trzeba zrobić coś poza tym łańcuchem. Lokatory i oczekiwania w Selenium opisujemy w tekstach o selektorach i waitach.

Playwright przydaje się także poza testami: gdy strona buduje treść w JavaScripcie, zwykłe zapytanie HTTP widzi pusty szkielet, a przeglądarka sterowana z Playwright widzi dane. Przykład w Pythonie, uruchomiony na stronie do ćwiczeń, pokazujemy w tekście o tym, czym jest web scraping i jak działa.

Czy przepisywać istniejący zestaw z Selenium na Playwright?

Istniejącego, działającego zestawu w Selenium nie przepisuje się dla samej nowości; migracja ma sens, gdy koszt utrzymania (padnięcia bez błędu w aplikacji, czas regresji, godziny na naprawę lokatorów) przekracza koszt przepisania, a wtedy robi się ją przyrostowo: nowe moduły w nowym narzędziu, stare testy wygaszane, gdy funkcje się zmieniają.

1. Zmierzcie koszt obecnego zestawu. Ile padnięć miesięcznie bez błędu w aplikacji, ile trwa regresja, ile godzin idzie na utrzymanie. Bez tej tabeli migracja jest życzeniem, nie decyzją.
2. Sprawdźcie, czy problem jest w narzędziu. Uśpienia, XPath po strukturze i brak Page Objectów przeniosą się do Playwrighta razem z testami. Większość „niestabilnego Selenium” to niestabilny kod testów.
3. Pilot na jednym module. Dziesięć testów krytycznych przepisanych w nowym narzędziu, uruchamianych obok starych przez miesiąc. Porównanie padnięć i czasu.
4. Migracja przyrostowa. Nowe funkcje testowane w nowym narzędziu, stare testy wygaszane przy okazji zmian w funkcjach, nie przepisywane hurtem.
5. Wspólna warstwa. Dane testowe, logowanie przez API, raportowanie i pipeline wspólne dla obu narzędzi, żeby migracja nie podwajała infrastruktury.

Największy zysk z migracji rzadko bierze się z narzędzia, częściej z tego, że przy okazji zespół przenosi logikę biznesową z interfejsu na API i porządkuje piramidę testów. Ten sam ruch da się zrobić bez zmiany narzędzia. Plan takiej przebudowy przygotowujemy w ramach automatyzacji testów.

Jakie błędy popełniają zespoły przy wyborze narzędzia?

Najczęstsze błędy to wybór po rankingu zamiast po profilu zespołu, Cypress do aplikacji z wieloma domenami, Selenium bez nikogo, kto zna język, Playwright wdrożony przez przepisanie działającego zestawu, porównywanie szybkości z cudzych benchmarków, pominięcie pilota i oczekiwanie, że narzędzie naprawi złą architekturę testów.

1. Ranking zamiast profilu. „Wszyscy przechodzą na Playwright” nie jest argumentem dla zespołu javowego z Appium i osiemset testami.
2. Cypress i wiele domen. Logowanie przez zewnętrznego dostawcę tożsamości i płatność w bramce to codzienność, o której zespół dowiaduje się w drugim tygodniu.
3. Selenium bez języka. Zespół manualny bez Javy ani Pythona kopiuje fragmenty z internetu. Playwright z codegen albo Maestro w mobile dają łagodniejszy start.
4. Migracja hurtem. Trzy miesiące przepisywania, w trakcie których nikt nie testuje nowych funkcji.
5. Cudze benchmarki. „O 42 procent szybszy” zmierzone na czyimś zestawie. Własny pilot z dziesięcioma uruchomieniami mówi prawdę o Waszej aplikacji.
6. Brak pilota. Decyzja na spotkaniu zamiast na danych z tygodnia pracy.
7. Narzędzie jako lekarstwo. Uśpienia, XPath po strukturze, logika przez interfejs i brak Page Objectów przeżyją każdą migrację.

Który język wybrać, zanim wybierzecie narzędzie, rozkładamy w tekście Jaki język programowania wybrać do automatyzacji testów. Pełny przegląd narzędzi testerskich, nie tylko do interfejsu, w tekście o narzędziach do testowania oprogramowania. Wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Powiązane na blogu Quality Island

• Selenium: co to jest, jak działa i od czego zacząć automatyzację testów
• Selenium WebDriver vs Cypress: które narzędzie do automatyzacji testów wybrać
• Narzędzia do automatyzacji testów aplikacji mobilnych: Appium, Espresso, XCUITest, Maestro, Detox i jak wybrać
• Piramida testów: co to jest, warstwy, proporcje i techniki projektowania testów
• Jaki język programowania wybrać do automatyzacji testów?
• Zalety i wady automatyzacji testów: kiedy się opłaca, a kiedy potrafi przepalić budżet

Pełna lista źródeł

• Playwright, playwright.dev: Getting started, Browsers, Actionability, Trace viewer, Codegen, kod źródłowy
• Cypress, Why Cypress, Trade-offs, Component testing, cennik Cypress Cloud, kod źródłowy
• Selenium, WebDriver oraz Grid
• Dane własne Quality Island z projektu dla Argos, e-commerce, liczby potwierdzone przez klienta; ponad 450 000 napisanych testów automatycznych