W artykule przybliżę Ci, co Playwright potrafi dziś w połączeniu z AI. Chcę też odpowiedzieć na pytanie, które ostatnio dość często pada na konferencjach i w rozmowach z zespołami: Czy Playwright rzeczywiście jest obecnie dobrym narzędziem open source do automatyzacji testów UI, jeśli patrzeć na niego przez pryzmat AI?
Od razu zaznaczę, że nie będzie to wpis w stylu „wpisujesz prompt i masz gotowy framework”. Pokażę Ci konkretne funkcje i powiem, co u mnie zadziałało, a co kosztowało mnie sporo eksperymentowania. Wszystkie wersje, komendy i flagi w tym tekście odnoszą się do Playwrighta 1.62.1, czyli wersji stabilnej na sierpień 2026.
Ta część to przegląd całości: co dokładnie dostajesz, jak to uruchomić i do czego się nadaje. W części drugiej wejdę głębiej – w reguły, które trzeba dopisać agentom, w koszt tokenowy MCP kontra CLI, w bezpieczeństwo i w debugowanie testów z agentem.
Co dokładnie Playwright oferuje w obszarze AI?
Dziś mamy do dyspozycji cztery obszary, które warto znać:
- Playwright Agents – trzej subagenci (planner, generator, healer), których definicję instalujesz jedną komendą.
- Playwright MCP – serwer MCP (Model Context Protocol) dający modelowi bezpośredni dostęp do przeglądarki.
- Playwright CLI – nowsze podejście, zoptymalizowane pod kątem zużycia tokenów.
- Debugowanie wspierane przez AI – m.in. przycisk „Copy prompt” w raporcie HTML, trace viewerze i UI mode, a od 1.59 również flaga
--debug=clii polecenienpx playwright trace, przeznaczone wprost dla agentów.
Każdy z tych elementów rozwiązuje trochę inny problem. Przejdźmy przez nie po kolei.
Playwright Agents
Playwright Agents to ciekawy pomysł na to, żeby trzech subagentów pomagało w codziennej pracy inżyniera automatyzacji testów. Funkcja pojawiła się w Playwrighcie 1.56 i dzieli się na trzy role:
- Planner – eksploruje uruchomioną aplikację w przeglądarce i tworzy plan testów w formacie Markdown. Dostajesz plik ze scenariuszami, warunkami wstępnymi, krokami i oczekiwanymi rezultatami. Najważniejsze jest to, że to artefakt czytelny dla człowieka, więc możesz go przejrzeć i poprawić, zanim ktokolwiek napisze linijkę kodu.
- Generator – zamienia zaakceptowany plan na pliki
.spec.ts. Nie robi tego „na sucho” na podstawie kodu źródłowego, tylko wykonuje kroki w żywej przeglądarce i weryfikuje lokatory na bieżąco. W wygenerowanym pliku zostawia komentarze// spec: i // seed:, wskazujące scenariusz i seed, z których wyrósł dany test. Drobiazg, ale bardzo ułatwia review. - Healer – zaczyna od uruchomienia całego zestawu testów, żeby ustalić, które testy nie przechodzą. Potem odtwarza kroki, w których wystąpił błąd, sprawdza bieżący stan UI w poszukiwaniu odpowiednika elementu lub przepływu, proponuje poprawkę i powtarza przebieg, dopóki test nie przejdzie albo dopóki nie zatrzymają go zabezpieczenia. Jeżeli uzna, że zepsuta jest aplikacja, a nie test, powinien pominąć test, zamiast zamiatać błąd pod dywan.
Dokumentacja (Playwrighta) stawia sprawę uczciwie: wynikiem pracy healera jest albo test przechodzący albo pominięty. Rzuca się przy tym w oczy jedno: healer nie dostaje ani jednego narzędzia do klikania. Jego lista to inspekcja strony, konsola, sieć,evaluate, generowanie lokatorów, wyszukiwanie w plikach i ich edycja oraz listowanie, uruchamianie i debugowanie testów. Naprawia kod, a nie interakcję.
Odczarujmy od razu ten mechanizm. Definicja agenta to zwykły plik Markdown: nagłówek z metadanymi, zestaw instrukcji i lista narzędzi MCP, które ten agent ma prawo wywołać. W nagłówku znajduje się też pole model:, a w 1.62.1 wszystkie trzy definicje mają tam wpisane sonnet. To znaczy, że wybór modelu nie jest w pełni Twoją decyzją w kliencie, tylko wartością w pliku, którą możesz zmienić, pamiętając, że kolejne init-agents wpisze ją z powrotem.
Jak to uruchomić?
Konfiguracja jest prosta. Potrzebujesz Playwrighta w wersji 1.56 lub nowszej i jednej komendy w katalogu projektu:
npx playwright init-agents --loop=vscode
# albo
npx playwright init-agents --loop=claude
Flaga --loop mówi Playwrightowi, dla jakiego klienta ma wygenerować definicje agentów. W 1.62 przyjmuje sześć wartości: claude, codex, copilot, opencode, vscode i vscode-legacy. Jeżeli sprawdzisz to w dokumentacji, znajdziesz tylko cztery - copilot i vscode-legacy wypisuje dopiero --help. Przy VS Code potrzebujesz wersji 1.105 lub nowszej, bo wcześniejsze nie mają pełnego wsparcia dla trybu agentowego.
Po uruchomieniu komendy dostajesz trzy pliki z definicjami agentów (po jednym na rolę), konfigurację serwera MCP, katalog specs/ z krótkim README oraz – jeżeli jeszcze go nie masz – tzw. seed test. Dokładne ścieżki zależą od wybranej wartości --loop: Claude Code dostaje definicje w .claude/agents/ i plik .mcp.json w katalogu projektu, a --loop=vscode zapisuje je jako .github/agents/<nazwa>.agent.md z wpisem w .vscode/mcp.json. Jeżeli szukasz chat mode’ów w .github/chatmodes/, to jest już ścieżka legacy, dostępna pod osobną flagą --loop=vscode-legacy. W repo zostaje więc specs/ z planami w Markdownie i tests/ z wygenerowanymi testami, a wśród nich tests/seed.spec.ts.
Kolejne kroki
Wygenerowanie plików to dopiero połowa sprawy, bo samo z siebie nic się nie uruchomi.
Agentów wywołujesz z czatu swojego klienta – w Claude Code prosząc o plannera, generator albo healera po nazwie, w VS Code wybierając jednego z listy agentów w czacie. Kolejność jest taka, jak zaprojektowano role: planner zapisuje plan w specs/, Ty przeglądasz ten Markdown, generator zamienia zaakceptowany plan na testy w tests/, a healer wchodzi dopiero wtedy, gdy coś już nie przechodzi.
Ważny element z dokumentacji: definicje agentów należy regenerować przy każdej aktualizacji Playwrighta, żeby podciągnąć nowe narzędzia i instrukcje. To nie jest kosmetyka, bo te pliki zawierają listę narzędzi MCP, a ta lista zmienia się między wersjami.
Jeżeli korzystasz już z Playwrighta w wersji 1.62 lub nowszej, jest jeszcze jedno ułatwienie: serwer MCP i CLI są teraz w tej samej paczce co Playwright, więc uruchomisz je przez npx playwright mcp i npx playwright cli, bez osobnej instalacji. To dziś domyślna droga, więc zacznij właśnie od niej. Obok init-agents doszła też komenda npx playwright init-skills instalująca skille Playwrighta dla Twojego klienta (--loop=claude albo --loop=agents). To osobny mechanizm w stosunku do definicji agentów i łatwo go przeoczyć, bo dokumentacja poświęca mu znacznie mniej miejsca.
Seed test
Jeden z tych plików zasługuje na więcej uwagi niż zwykle dostaje: seed test.
Wygląda jak pusta zaślepka, a w praktyce decyduje o tym, czy agent w ogóle zobaczy Twoją aplikację i w jakim stylu napisze testy. To również miejsce na logowanie. Planner i generator eksplorują żywą aplikację, więc jeżeli Twoja stoi za ekranem logowania, to właśnie seed test podaje im zalogowaną sesję przez storageState. Bez tego agent spędzi cały przebieg, wpatrując się w formularz logowania.
Jaka jest jakość wygenerowanego kodu?
I tutaj przechodzimy do sedna, bo to jest pytanie, które dostaję najczęściej.
Z mojej perspektywy, jeżeli nie dasz subagentom zasad, których mają przestrzegać, jakość wygenerowanego kodu będzie przeciętna. I nie chodzi o to, że kod nie będzie działał. Chodzi o to, że będzie działał w sposób, którego nie chcesz mieć w repozytorium.
To zresztą nie jest wyłącznie moja obserwacja. Dokumentacja Playwrighta sama zastrzega przy generatorze, że wygenerowane testy mogą zawierać błędy, które dopiero healer ma naprawić (Test Agents).
Drugi sygnał tej samej sprawy znajdziesz w definicji generatora. Przykład, na którym uczy się model, jest w playwright-test-generator.agent.md, w sekcji z instrukcją generowania kodu:
test('Add Valid Todo', async { page } => {
// 1. Click in the "What needs to be done?" input field
await page.click(...);
...
});
page.click() to stare API akcji na selektorze, a nie lokator – dokumentacja Playwrighta oznacza je jako discouraged i odsyła do locator.click(). Jeżeli zastanawiasz się, skąd w wygenerowanych testach biorą się konstrukcje, których nie chcesz w repo, to masz właśnie jedno ze źródeł.
Najbardziej bolesny przypadek, na jaki się natknąłem, dotyczył jednak healera. Zdarzało się, że agent zamiast sensownie poprawić test po prostu usuwał asercję albo znacząco upraszczał scenariusz. Test przechodził, metryka wyglądała dobrze, a wartość takiego testu spadała praktycznie do zera. I nie jest to anegdota, tylko konsekwencja tego, co healer ma zapisane w swojej definicji – rozbieram to na czynniki pierwsze w drugiej części artykułu, razem z listą reguł, które u mnie ten problem ograniczyły.
Podsumowując: agenci świetnie przyspieszają pierwszy przebieg i zbieranie dowodów. Nie zastępują natomiast review człowieka przy ścieżkach krytycznych pod względem biznesowym. Powiem wprost, na czym dziś stoję: agentów traktuję nadal jako obszar do eksperymentowania, a nie jako element procesu, na którym mógłbym polegać. Pewniej sprawdzają mi się MCP i CLI – tam widzę dokładnie, co dostaję, i sam decyduję, co z tym zrobić.
Playwright MCP
Playwright MCP to serwer, który daje modelowi zestaw narzędzi do sterowania przeglądarką: nawigacja, klikanie, wpisywanie tekstu, robienie snapshotów drzewa dostępności. Jeżeli to ostatnie pojęcie jest dla Ciebie nowe: drzewo dostępności to strona widziana tak, jak widzą ją technologie asystujące – role, nazwy i stany, bez szumu znaczników i stylów. Dlatego jest znacznie tańsze niż surowy HTML i znacznie bardziej użyteczne dla modelu niż zrzut ekranu.
Model nie zgaduje na podstawie kodu źródłowego, tylko operuje na realnie działającej stronie. Dlatego generowane lokatory są zwykle sensowne i oparte na rolach. Nie chodzi o to, że CSS jest zły, bo selektor oparty na stabilnym atrybucie czy na data-testid jest w porządku. Chodzi o to, że model, który strony nie widzi, sięga po pierwszy selektor znaleziony w kodzie, a taki zwykle rozpada się przy pierwszej zmianie struktury.
W domyślnej konfiguracji serwer wystawia 24 narzędzia: nawigację, kliknięcia, wpisywanie tekstu, snapshot drzewa dostępności, wyszukiwanie w snapshocie, zrzut ekranu, obsługę dialogów, podgląd requestów i kilka drobniejszych.
Po włączeniu wszystkich opcjonalnych grup narzędzi (w dokumentacji: capabilities) – network, storage, devtools, pdf, vision, testing i config – jest ich łącznie 69. Wszystkie siedem podajesz we fladze --caps, ale nie szukaj ich w --help: wypisuje dziś tylko vision, pdf i devtools. Zwróć uwagę zwłaszcza na testing: to stamtąd biorą się browser_generate_locator i rodzina browser_verify_*, czyli narzędzia zaprojektowane wprost pod pisanie asercji. Liczby dotyczą @playwright/mcp w wersji 0.0.79 i rosną z wydania na wydanie, więc traktuj je jak przejściowy stan, a nie stałą.
Playwright MCP w praktyce
Praktyczne zastosowania, które u mnie się sprawdziły:
- Eksploracja aplikacji i wyciąganie struktury HTML konkretnej strony.
- Generowanie page objectów dla nowego widoku.
- Szybkie prototypowanie scenariusza, zanim usiądę do pisania go na czysto.
I tutaj ważna uwaga, bo łatwo o skrót myślowy: Playwright Agents faktycznie działają na MCP, ale nie na tym serwerze, o którym mowa wyżej. init-agents konfiguruje wbudowany serwer o nazwie playwright-test, uruchamiany przez npx playwright run-test-mcp-server. Do tych samych narzędzi przeglądarkowych dokłada takie, których samodzielny @playwright/mcp nie ma: zapis i zatwierdzenie planu testów, generowanie pliku testowego oraz listowanie, uruchamianie i debugowanie testów przez test runner.
Innymi słowy: to jest nadzbiór, a nie ta sama paczka.
Playwright CLI
I tu dochodzimy do narzędzia, które moim zdaniem jest najciekawszą nowością ostatnich miesięcy.
Krótka uwaga na wypadek, gdyby ten skrót był dla Ciebie nowy. CLI to command line interface, czyli interfejs linii poleceń: zamiast klikać w GUI albo wywoływać narzędzia przez protokół, korzystasz z konsoli i wpisujesz komendy.
Playwright CLI (paczka @playwright/cli) to interfejs linii poleceń do automatyzacji przeglądarki, zaprojektowany z myślą o agentach kodujących.
W praktyce wygląda to tak:
# instalacja globalna - w projekcie masz to samo pod `npx playwright cli`
npm install -g @playwright/cli@latest
playwright-cli install-browser
# instalacja skilli dla Twojego agenta
playwright-cli install --skills
# przykładowa sesja
playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli snapshot
playwright-cli fill e8 "Write tests"
playwright-cli press Enter
playwright-cli screenshot
Zwróć uwagę na e8. To kompaktowa referencja do elementu, pochodząca ze snapshotu drzewa dostępności, który wylądował na dysku. Nie ma tu długich selektorów CSS ani całego drzewa w kontekście modelu. Numery są oczywiście przykładowe – u Ciebie ten sam element dostanie inny ref. Co ważniejsze: ref działa tylko do najbliższej zmiany strony; po nawigacji snapshot trzeba zrobić ponownie. Pętla pracy agenta wygląda więc tak: zrób snapshot, odczytaj z pliku potrzebny ref, wykonaj akcję, zrób kolejny snapshot.
Przy pisaniu testów liczy się jednak coś jeszcze, coś ważniejszego niż same tokeny: każda akcja wykonana przez playwright-cli zwraca odpowiadający jej kod Playwrighta w TypeScripcie. Nie musisz zgadywać, jak agent trafił w element, ani przepisywać tego z pamięci, bo dostajesz gotową linijkę do wklejenia do testu.
Warto też wiedzieć, że skill dostarczany razem z CLI to nie tylko spis komend. W references/test-generation.md znajdziesz kompletny przepływ „plan → generate → heal”: eksploracja aplikacji, zapis specyfikacji, wygenerowanie testów i diagnozowanie tych, które nie przechodzą – wszystko oparte na --debug=cli i attach, bez MCP i bez subagentów. To te same trzy role co w Playwright Agents, tylko przeniesione do warstwy CLI i opisane w Markdownie zamiast w definicjach agentów.
Pułapki
Zanim to narzędzie trafi do firmowego pipeline’u,sprawdź numery wersji: @playwright/cli jest dziś w wersji 0.1.x, podczas gdy sam Playwright jest w wersji 1.62.1. Paczka jest przed 1.0, więc komendy i flagi potrafią się zmienić między wydaniami. W CI przypnij konkretną wersję zamiast korzystać z @latest.
Jest tu jeszcze jedna pułapka. Przykłady wyżej używają globalnego playwright-cli, bo tak są napisane oficjalne skille, ale to nie to samo binarium co npx playwright cli z Twojego projektu: @playwright/cli 0.1.18 ciągnie za sobą własnego Playwrighta w wersji 1.63.0-alpha. Jeżeli zależy Ci na jednej wersji runnera i przeglądarki w całym repo, korzystaj z wariantu wbudowanego, a globalny zostaw do eksperymentów.
Sama dokumentacja Microsoftu stawia sprawę uczciwie: MCP i CLI to nie są narzędzia konkurencyjne, tylko komplementarne. MCP nadal ma sens tam, gdzie potrzebujesz trwałego stanu, bogatej introspekcji i iteracyjnego rozumowania nad strukturą strony. CLI wygrywa tam, gdzie agent musi jednocześnie obsługiwać przeglądarkę, duże repozytorium, testy i rozumowanie w ograniczonym oknie kontekstowym. Szczegółowe porównanie, razem z liczbami, znajdziesz w kolejnej części artykułu.
Debugowanie testów Playwright z AI
Czwarty obszar, który przybliżę, to debugowanie. I tu Playwright dołożył w ostatnich wydaniach najwięcej.
W skrócie masz dziś do dyspozycji:
- Copy prompt – przy każdym błędzie w raporcie HTML, w trace viewerze i w UI mode pojawia się przycisk kopiujący do schowka gotowy prompt z komunikatem błędu, fragmentem kodu testu i snapshotem strony. To najprostsza i, moim zdaniem, najbardziej niedoceniana funkcja, która jest z nami od 1.51.
- Fix with AI w VS Code – ikona iskierek przy komunikacie błędu, która analizuje kontekst i, korzystając z GitHub Copilota, proponuje poprawkę bezpośrednio w edytorze.
- Trace viewer – nadal moje główne narzędzie do debugowania i AI go nie zastąpiło. Zastąpiło natomiast żmudne przepisywanie tego, co w nim widzę, do okna czatu.
npx playwright trace– nowość z 1.59, która rozwiązuje bardzo konkretny problem: agent nie umie klikać w GUI trace viewera, ale potrafi odpytać trace komendami.--debug=cli –druga nowość z 1.59: test zatrzymuje się i wystawia jako sesję CLI, do której agent (albo Ty) może się podłączyć i przejść go krok po kroku z żywą przeglądarką.
Każde z tych narzędzi nadaje się do czego innego i każdemu poświęcam osobny fragment w części drugiej artykułu.
Testing & QA
Zapewnij jakość, wydajność i bezpieczeństwo swojego oprogramowania dzięki naszym usługom testowania i automatyzacji testów.
Oferta Testing&QACo z tego wynika?
Przez ostatni rok Playwright przeszedł drogę od „da się podpiąć MCP” do kompletnego zestawu narzędzi agentowych w standardzie.
Cztery obszary, przez które przeszliśmy, mają jedną wspólną cechę: żaden z nich nie zdejmuje z Ciebie review. Agenci przyspieszają start, MCP daje modelowi oczy, CLI mieści to wszystko w oknie kontekstowym, a debugowanie skraca drogę od czerwonego testu do przyczyny. Ale cokolwiek z nich wyjdzie – lokator, page object, szkic scenariusza, poprawka od healera – trafia do repo dopiero przez Twoje ręce. Model widział stronę, ale nie widział Twoich konwencji.
W drugiej części artykułu zejdę poziom niżej: pokażę reguły, które trzeba dopisać generatorowi i healerowi, dwa tryby awarii healera na konkretnych diffach, ile naprawdę kosztuje MCP w porównaniu z CLI, o czym trzeba pamiętać, wpuszczając agenta na realną aplikację, oraz jak wygląda debugowanie testu razem z agentem.
Zostaw komentarz