Playwright vs Cypress: dwie filozofie AI w testowaniu

Playwright i Cypress idą dziś w stronę AI, ale każdy z nich ma inny pomysł na to, gdzie to AI powinno mieszkać. Cypress coraz mocniej wkłada je do samego narzędzia testowego, a Playwright buduje infrastrukturę, z której korzystają zewnętrzni agenci - Claude Code, Copilot czy Cursor. Ta różnica wygląda na detal, dopóki nie zaczniesz się zastanawiać, kto w Twoim zespole będzie odpowiadał za jakość testu wygenerowanego przez AI.

Pracuję głównie z Playwrightem, ale od kilku miesięcy uważnie obserwuję też Cypressa. Nie dlatego, że planuję migrację, tylko dlatego, że Cypress pokazuje alternatywną drogę dla AI-assisted testing i zadaje pytania, których w ekosystemie Playwrighta często się nie zadaje. Jeśli Twój zespół siedzi w jednym frameworku, łatwo przyjąć jego wizję jako jedyną możliwą.

Jest też drugi, mniej medialny wątek. Cypress 16 wycofuje przeglądarkę Electron jako domyślne środowisko testów, bo wyniki potrafiły różnić się od tego, co widzą prawdziwi użytkownicy w Chrome. Na pierwszy rzut oka to zwykła zmiana techniczna, ale łączy się z AI przez jedną zasadę: szybki test ma małą wartość, jeżeli nie reprezentuje rzeczywistego systemu.

Co Cypress rozwija w obszarze AI?

Cypress zebrał swoje funkcje AI pod szyldem Cypress AI i rozłożył je na trzy etapy pracy: tworzenie testów, debugowanie i poprawę jakości. Najważniejsze elementy to cy.prompt, Studio AI, AI Skills i Cloud MCP. Część z nich działa w samej aplikacji Cypress, część wymaga Cypress Cloud - płatnej (z darmowym planem Starter) usługi do nagrywania i analizy przebiegów testów.

cy.prompt to komenda, która zamienia kroki opisane naturalnym językiem na zwykłe komendy Cypressa. Przekazujesz tablicę zdań w stylu "visit the login page" albo "click the login button", a AI na podstawie DOM buduje selektory i generuje kod. Komenda pojawiła się w Cypress 15.4.0, od 15.13.0 jest w becie, działa tylko w testach E2E, tylko w przeglądarkach opartych na Chromium i wymaga konta w Cypress Cloud.

Ciekawie rozwiązano dane wrażliwe. Wartości przekazane jako placeholders (np. hasło) nie trafiają do modelu i nie wpływają na cache, więc ten sam prompt w pętli nie wywołuje AI za każdym razem. W komplecie jest też self-healing, czyli automatyczna naprawa kroku, gdy zmieni się element docelowy - najpierw z użyciem zapisanych selektorów, a dopiero potem przez AI.

Studio AI działa inaczej. Klikasz po aplikacji w trybie nagrywania, a Studio obserwuje zmiany w DOM i proponuje assertions dla elementów, które się zmieniły. To rozwiązuje bardzo realny problem nagranych testów: kroki są, ale niczego nie weryfikują. Funkcja pojawiła się w Cypress 15.11.0, a rekomendacje są darmowe na czas bety.

Dwa ostatnie elementy są skierowane do zewnętrznych agentów. AI Skills to otwartoźródłowe pakiety instrukcji (cypress-author, cypress-explain, cypress-docs), które uczą Twojego agenta dobrych praktyk Cypressa - pisania i naprawiania testów, objaśniania istniejących i odpowiadania na pytania o dokumentację. Cloud MCP udostępnia agentowi dane z Cypress Cloud: błędy, historię komend, konsolę, ruch sieciowy, Test Replay, luki w UI Coverage i naruszenia accessibility.

MCP (Model Context Protocol) to standard, przez który asystent AI może korzystać z zewnętrznych narzędzi i danych. W praktyce oznacza to, że agent w Twoim edytorze może sam zajrzeć do wyników z CI, zobaczyć, który test jest flaky i dlaczego, a potem zaproponować poprawkę. Do tego dochodzi cypress tap z wersji 15.21.0, który pozwala agentowi uruchamiać specy i czytać Command Log bezpośrednio z terminala.

Co robi Playwright?

Playwright nie ma odpowiednika cy.prompt ani wbudowanego generatora asercji w stylu Studio AI. Zamiast tego od kilku wersji konsekwentnie rozbudowuje warstwę, z której mogą korzystać agenci działający poza frameworkiem. W najnowszej wersji 1.64 widać to wyraźniej niż kiedykolwiek, bo większość nowości w release notes dotyczy właśnie agentów.

Przełomem była wersja 1.56 i Playwright Test Agents. To trzy definicje agentów, które prowadzą model językowy przez proces tworzenia testu: planner eksploruje aplikację i pisze plan testów w Markdown, generator zamienia plan w pliki testowe, a healer uruchamia testy i naprawia te, które padają. Komenda npx playwright init-agents generuje te definicje dla VS Code, Claude Code albo opencode - czyli dla narzędzia, którego zespół już używa.

Kolejne wersje dokładały infrastrukturę. W 1.59 pojawiło się npx playwright test --debug=cli, przez które agent może podłączyć się do debugowanego testu, oraz npx playwright trace do przeglądania trace'ów z terminala. Od 1.62 serwer Playwright MCP i playwright-cli są dołączone do samego Playwrighta, a w 1.64 doszła obsługa WebMCP, czyli eksperymentalnego API, przez które strona może sama wystawiać narzędzia dla agentów.

Wspólny mianownik jest prosty: Playwright nie próbuje być Twoim asystentem AI. Daje agentowi oczy (aria snapshoty, trace'y, nagrania wideo), ręce (MCP i CLI do sterowania przeglądarką) oraz gotowe role do odegrania. Sam model, jego koszt i jego konfiguracja zostają po Twojej stronie.

AI w produkcie czy infrastruktura dla agentów?

Cypress coraz mocniej wkłada AI do samego produktu testowego, a Playwright coraz mocniej buduje infrastrukturę, z której korzystają zewnętrzni agenci. To nie jest podział zero-jedynkowy, bo Cypress też ma AI Skills i Cloud MCP dla agentów. Różni się jednak środek ciężkości: w Cypressie AI jest częścią doświadczenia narzędzia, w Playwrighcie jest gościem, któremu framework przygotowuje dobre warunki pracy.

Różnicę najłatwiej zobaczyć, gdy przełożysz ją na pytania, które zadaje sobie zespół przy wyborze sposobu pracy z AI. Nie traktuj ich jako testu "który framework wybrać", bo oba ekosystemy się do siebie zbliżają. Chodzi raczej o to, który model pracy z AI jest bliższy Twojemu zespołowi dziś:

• Chcesz, żeby AI dawało wartość od razu, bez konfigurowania własnego agenta? -> bliżej Ci do Cypressa i cy.prompt.

• Zespół ma już ulubionego agenta (Claude Code, Copilot, Cursor) i chce go używać także do testów? -> bliżej Ci do Playwrighta i Test Agents.

• Największy problem to nagrane testy, które klikają, ale niczego nie sprawdzają? -> Studio AI z rekomendacjami assertions celuje dokładnie w ten problem.

• Chcesz sam decydować, jaki model pracuje na Twoim kodzie i ile za to płacisz? -> infrastruktura Playwrighta (MCP, playwright-cli) zostawia ten wybór Tobie.

• Wyniki z CI i tak trzymasz w Cypress Cloud? -> Cloud MCP da agentowi dostęp do błędów, Test Replay i flaky testów bez dodatkowej integracji.

• Testujesz iframe'y, canvas, wiele elementów naraz albo piszesz kroki po polsku? -> cy.prompt ma tu ograniczenia, więc przy takich scenariuszach i tak potrzebujesz klasycznej automatyzacji lub agenta z pełnym dostępem do kodu.

• Nie macie spisanych standardów projektu testowego? -> zacznij od nich, bo bez nich żadne z tych podejść nie da dobrych testów.

Obie drogi mają sens i obie mają koszt. Podejście Cypressa obniża próg wejścia, bo tester nie musi konfigurować agenta, żeby dostać pierwszą wartość z AI - wystarczy Cypress i konto w Cloud. Ceną jest zależność od dostawcy: model, limity użycia i sposób działania self-healingu ustala producent narzędzia, a nie Twój zespół.

Podejście Playwrighta daje więcej kontroli, ale wymaga więcej dojrzałości. Ktoś musi wybrać agenta, opisać standardy projektu, pilnować, co agent commituje i jak wygląda review jego pracy. W zespole bez ustalonych zasad infrastruktura dla agentów szybko zamienia się w generator setek testów E2E, których nikt nie rozumie.

Dla rynku QA to dobra wiadomość. Zaczyna powstawać realna konkurencja pomysłów na to, jak powinien wyglądać AI-assisted testing, zamiast jednej wizji narzuconej przez jednego gracza. A konkurencja pomysłów zwykle oznacza, że oba frameworki będą się nawzajem podglądać - co zresztą już widać po AI Skills i Cloud MCP w Cypressie.

Na co uważać, zanim wpuścisz AI do testów?

Niezależnie od frameworka AI przyspiesza pisanie testu, ale nie zdejmuje z QA odpowiedzialności za wybór scenariusza. Model zna strukturę DOM i repozytorium, ale nie zna ryzyka biznesowego, nie wie, która ścieżka zakupowa generuje większość przychodu i nie był na refinemencie, na którym ustalono wyjątki. Dlatego zanim zaczniesz porównywać funkcje, warto ustalić, kto w zespole decyduje, co wymaga ochrony testem.

Druga rzecz to ograniczenia, o których marketing mówi ciszej. cy.prompt nie obsługuje m.in. asercji na wielu elementach, asercji "nie istnieje" w języku naturalnym, cy.request(), iframe'ów, canvasu ani przewijania do elementu, a prompty są zoptymalizowane pod angielski. To wystarcza do prostych ścieżek, ale w aplikacji z osadzonymi płatnościami w iframe szybko trafisz na ścianę.

Trzecia to self-healing, który w obu ekosystemach brzmi świetnie. Test, który sam się naprawia, może też sam się dopasować do błędu - jeśli przycisk zniknął z powodu regresji, a AI znalazło "podobny" element, dostajesz zielony pipeline i bug na produkcji. Dlatego każdą automatyczną naprawę traktowałbym jak pull request do review, a nie jak gotowe rozwiązanie.

Czwarta to koszty i dane. cy.prompt jest rozliczany za wykonania promptów w ramach limitu organizacji, a w Playwrighcie płacisz za tokeny agenta, którego sam wybrałeś. W obu przypadkach warto sprawdzić, jakie dane z aplikacji trafiają do modelu - placeholdery w cy.prompt są dobrym przykładem, że ktoś o tym pomyślał, ale nie zwalniają z czytania dokumentacji.

Dlaczego Cypress 16 wycofuje Electron?

Od Cypress 16.0.0 (wydanego 1 września 2026) wbudowana przeglądarka Electron jest oznaczona jako deprecated jako przeglądarka testowa. Na razie nadal działa, ale wyświetla ostrzeżenie, a w przyszłej wersji major zostanie usunięta - Cypress nie podał jeszcze daty i obiecuje przewodnik migracji z wyprzedzeniem. Firma chce standaryzować testowanie na zainstalowanych przeglądarkach, takich jak Chrome czy Chrome for Testing.

Powody są bardzo "testerskie". Chromium w Electronie potrafi odstawać od stabilnego Chrome o tygodnie albo miesiące, a sam Electron nie jest przeglądarką, z której korzystają użytkownicy. Cypress opisuje przypadki, w których test przechodził w Electronie i padał w Chrome - m.in. przy renderowaniu, obsłudze plików, dialogach beforeunload i uploadzie dużych plików.

Dla zespołów oznacza to konkretną pracę w CI. Trzeba zainstalować przeglądarkę (np. przejść z obrazu cypress/base na cypress/browsers), ustawić defaultBrowser w konfiguracji albo przekazywać --browser w komendzie i usunąć odwołania do Electrona w kodzie testów. Jeśli Twój pipeline polegał na domyślnym Electronie, po jego usunięciu runy po prostu zaczną padać z błędem.

Ta decyzja niewiele ma wspólnego z AI, a jednak pokazuje tę samą zasadę, o której pisałem przy self-healingu: szybki test ma małą wartość, jeżeli nie reprezentuje rzeczywistego systemu. Zielony wynik w przeglądarce, której nie używa żaden klient, daje fałszywe poczucie bezpieczeństwa - dokładnie tak samo jak test naprawiony przez AI, który przestał sprawdzać to, co miał sprawdzać.

Co z tego wynika dla zespołu QA?

Jeśli pracujesz w Playwrighcie, nie musisz zmieniać frameworka, żeby skorzystać z obserwacji Cypressa. Studio AI podsuwa dobre pytanie: czy Twój agent proponuje sensowne asercje, czy tylko odtwarza kliknięcia? Z kolei limity cy.prompt przypominają, że AI najlepiej radzi sobie z prostymi ścieżkami, a najtrudniejsze scenariusze - iframe'y, płatności, zależności między danymi - nadal wymagają człowieka, który rozumie system.

Jeśli pracujesz w Cypressie, warto potraktować cy.prompt jako narzędzie do szybkiego szkicu, a nie zamiennik przemyślanej architektury testów. Wygenerowany kod to zwykłe komendy Cypressa, więc możesz go przejrzeć, uprościć i włączyć do istniejących standardów projektu. A migrację z Electrona lepiej zaplanować teraz, póki ostrzeżenie jest tylko ostrzeżeniem.

W obu przypadkach wybór frameworka staje się też wyborem modelu pracy z AI. Jedni wolą narzędzie, które "po prostu działa" w ramach jednego dostawcy, inni wolą złożyć własny zestaw z agenta, MCP i dobrze opisanych standardów. Żadna z tych dróg nie zwalnia jednak z najważniejszego pytania QA: czy ten test, szybki czy wygenerowany, naprawdę reprezentuje to, co zobaczy użytkownik?

Jeśli chcesz sprawdzić, jak pracować z AI w testowaniu bez względu na framework, zajrzyj do Prompt Hub dla testerów i QA - bazy promptów do Playwrighta, DevTools, Swaggera i CI/CD, którą rozwijamy razem ze społecznością: Prompt Hub dla testerów i QA.

Kontakt

kontakt@rwasik.pl

Znajdziesz mnie też tu

Newsletter