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.

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.

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.

Najczęstsze pytania o Selenium, Cypress i Playwright

Co to jest Playwright?

Playwright to otwarta biblioteka i framework testowy od Microsoftu do automatyzacji przeglądarek. Steruje Chromium, Firefoksem i WebKitem jednym interfejsem, działa w TypeScripcie, JavaScripcie, Pythonie, Javie i .NET, czeka automatycznie na gotowość elementów i zapisuje ślad wykonania testu z zrzutami, siecią i konsolą.

Co to jest Cypress?

Cypress to framework do testów end to end i komponentów w JavaScripcie i TypeScripcie, w którym test działa wewnątrz przeglądarki obok aplikacji. Daje podgląd na żywo, automatyczne ponawianie poleceń i wbudowane zrzuty, a jego ograniczenia to jedna domena naraz w teście, ograniczone ramki i karty oraz brak innych języków.

Selenium czy Playwright: co wybrać?

Playwright dla nowych projektów bez narzuconego języka, ze względu na automatyczne oczekiwanie, trace viewer i równoległość bez infrastruktury. Selenium dla zespołów w Javie, C#, Ruby lub Kotlinie, przy automatyzacji mobilnej w Appium, przy testach na prawdziwym Safari i przy istniejącym działającym zestawie.

Cypress czy Playwright: co wybrać?

Cypress dla zespołu frontendowego testującego własną aplikację jednostronicową i jej komponenty, w JavaScripcie. Playwright, gdy w grę wchodzą wiele domen, karty, Safari przez WebKit, inne języki albo równoległość bez płatnej usługi.

Które narzędzie jest najszybsze?

Z architektury wynika, że Playwright, bo używa trwałego połączenia z przeglądarką zamiast protokołu HTTP na każde polecenie jak Selenium. Konkretne procenty z blogów zależą od mierzonego zestawu; wiarygodną liczbę daje tylko własny pilot na Waszej aplikacji.

Czy Selenium jest przestarzałe?

Nie. Selenium jest standardem W3C, jest aktywnie rozwijane 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 Safari i automatyzacji mobilnej w Appium pozostaje pierwszym wyborem.

Czy warto przepisać testy z Selenium na Playwright?

Tylko wtedy, gdy koszt utrzymania obecnego zestawu (padnięcia bez błędu w aplikacji, czas regresji, godziny na naprawy) przekracza koszt migracji, i wtedy przyrostowo, nie hurtem. Większość problemów „niestabilnego Selenium” to problemy kodu testów, które przeniosą się do nowego narzędzia.

Czy Playwright obsługuje Safari?

Playwright steruje WebKitem, czyli silnikiem Safari, na Linuksie, macOS i Windows, ale nie samą przeglądarką Safari. Do testów na zainstalowanym Safari służy Selenium przez safaridriver.

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