Selenium vs Cypress vs Playwright: które wybrać w 2026?

To pytanie nie jest już o to, które narzędzie jest modne. To decyzja o tym, ile czasu firma będzie spalać na utrzymanie testów end to end, jak szybko zobaczy wynik z pipeline i jak często zespół będzie tłumaczył, że wydanie się opóźnia, bo testy znowu zgłupiały. Dobra wiadomość: wybór da się uprościć, jeśli przestaniecie myśleć nazwami narzędzi, a zaczniecie myśleć trzema osiami: stabilność, łatwość diagnozy, koszt utrzymania.

Poniżej porównanie na tych trzech osiach, konkretne warunki „kiedy wybrać, a kiedy odpuścić” dla każdego narzędzia, sposób na uczciwe porównanie w jeden dzień i rachunek, o którym w takich zestawieniach mówi się najrzadziej. Nie znajdziecie tu tabeli z liczbą gwiazdek na GitHubie, bo ona nie mówi nic o tym, ile kosztuje Was piątkowe wydanie.

Trzy narzędzia w jednej tabeli

Selenium: mocne w starszych systemach, droższe w utrzymaniu

Selenium nadal jest żywe, ale jego siła leży dziś gdzie indziej niż dekadę temu. Nie wygrywa tym, że jest najwygodniejsze. Wygrywa tym, że jest standardem, który latami obrósł procesami, bibliotekami i kompetencjami. W dużych organizacjach bywa nie tylko narzędziem, ale elementem architektury jakości: wpiętym w pipeline, raportowanie, polityki bezpieczeństwa, czasem w umowy i audyty. Do tego doszedł WebDriver BiDi, standard W3C, który dokłada połączenie WebSocket i strumień zdarzeń z przeglądarki, zamykając najpoważniejszy zarzut architektoniczny.

Nowoczesna ekonomia testów jest jednak bezlitosna. Nie liczy się, czy da się napisać test, tylko ile kosztuje utrzymanie go przez rok. Selenium wymaga dyscypliny: dobrego modelu oczekiwania, sensownego wzorca organizacji kodu, stabilnej infrastruktury, przemyślanej równoległości. Bez tego testy zachowują się jak loteria, a firma płaci opóźnieniami wydań i spadkiem zaufania do automatyzacji. Selenium nie przegrywa technicznie. Przegrywa ekonomią utrzymania tam, gdzie organizacja nie ma dojrzałości, żeby je prowadzić. Szerzej o tym, co realnie zmieniło się w tym narzędziu, piszemy w tekście o tym, dlaczego śmierć Selenium ogłoszono zbyt wcześnie.

Cypress: szybki start i ergonomia, skala bywa momentem prawdy

Cypress trafił w potrzeby zespołów frontendowych, bo daje szybki start i poczucie, że testy są częścią developmentu, a nie osobnym światem. Największa przewaga to moment wejścia: instalujecie, odpalacie, piszecie pierwszy test i automatyzacja przestaje być projektem na kwartał. Dla wielu zespołów to różnica między testami, które powstaną, a testami, które zostaną na roadmapie na zawsze. Do tego dochodzą testy komponentów, które pozwalają sprawdzać elementy interfejsu w izolacji, bez uruchamiania całej aplikacji.

Cypress ma też przewagę kulturową, której nie da się zignorować. Jeśli deweloperzy czują, że narzędzie jest ich, że mogą je odpalać lokalnie i poprawiać bez proszenia QA o rytuały, testy rosną szybciej i częściej są traktowane jak kod produkcyjny. Największym problemem automatyzacji nie jest framework, tylko brak odpowiedzialności za testy, a Cypress tę odpowiedzialność potrafi wywołać. Moment prawdy przychodzi przy skali: więcej testów, więcej równoległych uruchomień, większa różnorodność środowisk. Wtedy komfort pisania przestaje być najważniejszy, a zaczyna liczyć się to, jak testy żyją w pipeline.

Playwright: najlepszy bilans w nowych projektach

Playwright w nowych projektach najczęściej daje najlepszy bilans, bo rozwiązuje dwa najbardziej kosztowne problemy testów przez interfejs. Po pierwsze stabilność: dokumentacja narzędzia wprost zaleca testowanie zachowania widocznego dla użytkownika i lokatory oparte na roli, etykiecie i tekście, zamiast na szczegółach implementacji. To brzmi jak drobiazg, a jest różnicą między testem, który przeżyje refaktor komponentu, a testem, który padnie przy zmianie klasy CSS.

Po drugie diagnoza. Kiedy test pada w CI, nie chcecie wracać do archeologii logów. Chcecie odtworzyć, co się stało. Podgląd śladu wykonania pokazuje kolejne kroki, stan strony przy każdym z nich, ruch sieciowy i zrzuty ekranu. Awaria testu przestaje być śledztwem, a staje się szybką diagnozą. To zmienia dynamikę pracy bardziej niż jakakolwiek liczba w porównaniu wydajności.

Najważniejsze jest jednak to, że Playwright zwykle lepiej broni się po kilku miesiącach. Na początku prawie każde narzędzie wygląda dobrze. Różnica wychodzi przy kilkudziesięciu scenariuszach, zmianach w interfejsie co sprint i rosnącej liczbie środowisk. Wtedy liczy się, czy testy są przewidywalne i czy utrzymanie nie staje się drugim etatem.

Kiedy wybrać, a kiedy odpuścić

Osobny temat, który w takich porównaniach robi najwięcej zamieszania, to Safari i urządzenia mobilne. Kluczowe pytanie nie brzmi, czy narzędzie wspiera Safari, tylko co dla Was znaczy Safari. Desktop na Macu, silnik WebKit czy prawdziwy system iOS na realnych urządzeniach. To trzy różne koszty, trzy różne ryzyka i trzy różne infrastruktury. Jeśli iOS jest krytyczny, wybór narzędzia powinien iść w parze z decyzją, gdzie i jak uruchamiacie testy, bo samo narzędzie nie rozwiąże problemu środowiska.

Koszt, o którym nikt nie mówi: testy end to end to rachunek miesięczny

Testy przez interfejs to nie koszt jednorazowy. To rachunek, który przychodzi co sprint, tylko rzadko jest wystawiany fakturą wprost. Najpierw płacicie minutami w CI, potem czasem ludzi, a na końcu reputacją jakości, bo zespół zaczyna traktować te testy jak hałas. Najbardziej zdradliwe jest to, że koszt rośnie po cichu. Na początku kilka scenariuszy, wszystko działa szybko. Potem pięć kolejnych, bo doszły płatności. Potem ktoś dorzuca ponowne uruchomienie, bo raz na dziesięć przebiegów coś się wysypie. I nagle pipeline, który miał trwać dziesięć minut, trwa czterdzieści. Nikt nie czuje, że to była jedna decyzja, bo to był ciąg małych ustępstw.

Dłuższe uruchomienia kosztują podwójnie: dosłownie, bo zużywają zasoby, i organizacyjnie, bo wydłużają pętlę informacji zwrotnej. Jeśli deweloper dostaje informację o błędzie po czterdziestu minutach, jest już w innym kontekście. Naprawa boli bardziej, a następnym razem chętniej powie, że może włączymy te testy tylko na noc. Tak rodzi się degradacja jakości w CI. Niestabilne testy są jeszcze droższe, bo kosztują zaufanie: każdy fałszywy alarm to mikroskopijny podatek nakładany na zespół, a po miesiącu nikt nie pamięta liczby, ale wszyscy pamiętają emocję.

Najlepszy framework to często ten, który nie wygrywa w dyskusji, tylko wygrywa w pipeline. Koszt testów przez interfejs nie jest funkcją ich liczby, tylko tego, jak szybko potraficie wrócić do prawdy: czy to błąd produktu, błąd testu, błąd środowiska, czy po prostu pech. Jeśli narzędzie skraca drogę do tej odpowiedzi, oszczędzacie pieniądze nawet wtedy, gdy nikt nie umie tego policzyć w arkuszu. Prosty test dojrzałości: jeśli testy end to end są u Was uruchamiane rzadziej niż przy każdym scaleniu zmian, bo są za wolne albo zbyt niepewne, płacicie ten rachunek już teraz, tylko nie wiecie, ile wynosi.

Podsumowanie

Wybór między Selenium, Cypressem i Playwrightem jest dziś decyzją o koszcie utrzymania i długości pętli informacji zwrotnej, nie o tym, co jest modne. Selenium zostaje tam, gdzie jest wpięte w procesy i gdzie migracja kosztowałaby więcej niż utrzymanie. Cypress wygrywa tam, gdzie liczy się szybkie wejście i odpowiedzialność deweloperów za testy. Playwright najczęściej wygrywa w nowych projektach, bo daje przewidywalność i szybką diagnozę. Nie musicie wybierać jednego na zawsze: hybryda z jasnymi granicami jest dziś normą.

W Quality Island prowadzimy krótkie warsztaty i próbne wdrożenia, które kończą się rekomendacją, a nie prezentacją: jeden krytyczny scenariusz, jeden dzień, twarde wyniki z CI. Uczymy też zespoły pracy z Playwrightem w praktyce, jeśli decyzja już zapadła. A jeśli chcecie zacząć samodzielnie, zacznijcie od czterech kroków z ramki wyżej. Godzina przygotowania i dwadzieścia przebiegów powiedzą Wam więcej niż wszystkie zestawienia w internecie.