Playwright po polsku - Stabilne testy E2E od podstaw!

Playwright po polsku ma sens wtedy, gdy od razu widać, jak to narzędzie pomaga pisać stabilne testy bez walki z losowymi timeoutami. Ten tekst prowadzi od tego, czym Playwright faktycznie jest, przez pierwszy start i dobre praktyki, aż po porównanie z innymi popularnymi frameworkami. Jeśli wdrażasz automatyzację testów albo chcesz uporządkować istniejący zestaw e2e, znajdziesz tu konkretne wskazówki, a nie katalog ogólników.

Jak działa Playwright i gdzie daje przewagę

W praktyce Playwright jest frameworkiem do automatyzacji przeglądarki, który pozwala wykonywać testy tak, jak robi to realny użytkownik. To ważne, bo w przeciwieństwie do podejścia opartego wyłącznie na manipulacji DOM-em dostajesz kontrolę nad całym kontekstem przeglądarki, a nie tylko nad pojedynczym elementem strony. Dla zespołów produktowych oznacza to mniej „magicznych” błędów i lepsze odwzorowanie prawdziwych scenariuszy.

Największą różnicę widzę w trzech obszarach. Po pierwsze, Playwright testuje nowoczesne aplikacje webowe w kilku silnikach renderujących, więc łatwiej sprawdzić, czy logika nie psuje się tylko w jednej przeglądarce. Po drugie, ma własny runner testów, asercje i narzędzia do debugowania, więc nie trzeba sklejać wszystkiego z osobnych klocków. Po trzecie, dobrze wspiera scenariusze, które w automatyzacji są po prostu istotne: logowanie, checkout, formularze, wyszukiwarki, płatności i wszystkie ścieżki, których awaria kosztuje najwięcej.

Ja traktuję Playwright jako narzędzie do testów end-to-end, smoke i regresji krytycznych ścieżek. Nie próbowałbym nim zastąpić unit testów ani testów integracyjnych tam, gdzie szybsza i tańsza warstwa daje lepszy feedback. To raczej mocny element większej strategii jakości niż samodzielna odpowiedź na wszystko. Skoro wiesz już, za co odpowiada ten framework, czas przejść do pierwszego uruchomienia.

Jak zacząć pisać pierwsze testy bez zbędnej konfiguracji

Najprostszy start nie wymaga długiego przygotowania środowiska. Oficjalny starter prowadzi przez konfigurację projektu, pobranie przeglądarek i pierwszy test, więc próg wejścia jest wyraźnie niższy niż w starszych narzędziach. Jeśli pracujesz w JavaScript albo TypeScript, to właśnie tam ekosystem jest najbardziej dopracowany, ale Playwright wspiera też Python, Javę i .NET.

1. Zainicjuj projekt komendą npm init playwright@latest.
2. Wybierz język, przeglądarki i podstawową strukturę katalogów.
3. Uruchom przykładowy test i sprawdź raport HTML, żeby zobaczyć, jak wygląda wynik wykonania.
4. Wygeneruj pierwszy scenariusz przez npx playwright codegen i potraktuj go jako punkt wyjścia, a nie gotowy kod produkcyjny.

To właśnie generator testów zwykle daje najszybszy efekt na początku. Otwiera przeglądarkę, rejestruje akcje i proponuje locatory, które najczęściej opierają się na roli, tekście albo identyfikatorze testowym. Dzięki temu można szybko przejść od „nie wiem, jak to opisać” do działającego szkicu testu, który później dopracowuje się ręcznie.

import { test, expect } from '@playwright/test';

test('strona główna się otwiera', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  await expect(page.getByRole('heading', { name: 'Playwright' })).toBeVisible();
});

Ten przykład jest celowo prosty. Pokazuje dwie rzeczy, które w automatyzacji mają większe znaczenie niż efektowny kod: przejrzysty scenariusz i asercję, która sprawdza realny stan strony. Z takiego minimum łatwiej później budować kolejne testy, zamiast od razu rozwiązywać problemy z konfiguracją. Kiedy testy zaczynają powstawać szybciej, najważniejsze staje się to, jak je lokalizować i utrzymać stabilnie.

Locatory, auto-waiting i tracing

Jeżeli miałbym wskazać jeden obszar, który naprawdę odróżnia Playwright od wielu starszych podejść, to byłyby właśnie locatory. Locator to sposób wskazywania elementu w taki sposób, aby test trzymał się tego, co widzi użytkownik, a nie tego, jak akurat zbudowany jest DOM. Dzięki temu testy są odporniejsze na drobne zmiany w strukturze strony.

Auto-waiting to drugi powód, dla którego testy w Playwright często są mniej kapryśne. Framework przed akcją sprawdza między innymi, czy element jest widoczny, stabilny, gotowy do interakcji i faktycznie przyjmuje zdarzenia. W praktyce oznacza to mniej ręcznych pauz, mniej „losowych” timeoutów i mniej prób zgadywania, ile milisekund trzeba jeszcze odczekać.

Do debugowania bardzo dobrze służy też tracing. Trace to zapis przebiegu testu, który pozwala później prześledzić krok po kroku, co dokładnie się wydarzyło, jak wyglądała strona i na którym etapie coś się rozjechało. Przy flaky testach to różnica między godziną zgadywania a kilkoma minutami konkretnej analizy. Z takimi narzędziami łatwiej przejść od pojedynczego testu do pracy zespołowej i automatyzacji w CI.

Jak wykorzystać Playwright w zespole i w CI

W dobrze ustawionym zespole Playwright nie kończy się na jednym pliku z testem. To raczej zestaw praktyk: konfiguracja wielu projektów, sensowne przygotowanie danych, izolacja testów i kontrola kosztu uruchomień. Właśnie tu zaczyna się różnica między „działa na moim laptopie” a pipeline’em, który daje realny sygnał jakości.

Na start warto myśleć o trzech rzeczach. Po pierwsze, o konfiguracji przeglądarek: Playwright pozwala uruchamiać testy na Chromium, Firefox i WebKit, a także w emulowanych wariantach mobilnych. Po drugie, o izolacji przez fixtures, czyli gotowe zasoby przygotowywane przed testem i sprzątane po nim. Po trzecie, o tym, jak długo ma trwać pełny przebieg. Krótki, przewidywalny pipeline ma większą szansę stać się codziennym narzędziem zespołu niż rozbudowany zestaw, który wszyscy omijają.

• Uruchamiaj szybkie testy w trybie headless w CI, a tryb headed zostaw do lokalnego debugowania.
• Cache’uj pobrane przeglądarki, bo ich zestaw potrafi zająć kilkaset megabajtów i szkoda pobierać go przy każdym buildzie.
• Włączaj trace i zrzuty tylko dla nieudanych uruchomień albo krytycznych scenariuszy, żeby nie zaśmiecać artefaktów.
• Rozdziel testy smoke od cięższej regresji, zamiast wrzucać wszystko do jednego, długiego biegu.
• Jeżeli aplikacja ma różne środowiska, ustaw `baseURL` i używaj jednej konwencji adresowania, żeby nie powielać tych samych wartości w każdym teście.

W CI ważna jest też aktualizacja narzędzia. Playwright i pobrane przeglądarki powinny iść w parze, bo każda większa zmiana wersji może wymagać ponownego instalowania binarek. Dla zespołu to nie jest wada, tylko koszt utrzymania, który trzeba świadomie uwzględnić. Gdy ten fundament jest już ustawiony, sensowniejsze staje się pytanie, kiedy wybrać właśnie Playwright, a kiedy zostać przy innym narzędziu.

Kiedy Playwright wygrywa z Selenium i Cypress

Porównania narzędzi mają sens tylko wtedy, gdy odnoszą się do konkretnego problemu. Z mojego doświadczenia Playwright jest szczególnie mocny tam, gdzie liczy się nowoczesny front, stabilność testów i brak ciężkiej konfiguracji wokół przeglądarek. Nie oznacza to jednak, że zawsze wygrywa z każdym innym podejściem.

Jeśli miałbym dać prostą rekomendację, wybrałbym Playwright wtedy, gdy startujesz z nowym zestawem testów i nie chcesz budować całego ekosystemu wokół samego uruchamiania przeglądarki. Selenium nadal ma sens w dużych, starszych środowiskach, a Cypress bywa wygodny tam, gdzie cały zespół żyje frontem i ceni bardzo prosty feedback loop. Wybór nie jest religią, tylko decyzją o tym, gdzie chcesz zapłacić koszt konfiguracji i utrzymania. To naturalnie prowadzi do pytań o błędy, które najczęściej psują takie wdrożenia.

Najczęstsze błędy, które psują stabilność testów

• Używanie długich selektorów CSS albo XPath jako domyślnej strategii. To działa do pierwszej większej zmiany w DOM-ie, a potem test zaczyna pękać bez żadnej wartości biznesowej.
• Maskowanie problemów przez `waitForTimeout`. Stałe czekanie nie usuwa przyczyny flake’a, tylko ją przykrywa, przez co błędy wracają w najmniej wygodnym momencie.
• Łączenie zbyt wielu kroków w jednym scenariuszu. Jeśli jeden test obejmuje cały proces biznesowy od logowania do kilku różnych akcji, trudniej ustalić, co faktycznie się zepsuło.
• Brak izolacji danych. Testy, które zależą od wspólnego konta, wspólnego koszyka albo wspólnego stanu sesji, bardzo szybko zaczynają być losowe.
• Sprawdzanie szczegółów implementacyjnych zamiast efektu widocznego dla użytkownika. Asercja powinna mówić coś o zachowaniu aplikacji, a nie tylko o tym, że komponent ma akurat taki a taki kawałek HTML.

Najlepsza korekta tych błędów jest zwykle prosta, choć nie zawsze szybka: wybierz jeden standard locatorów, trzymaj testy krótkie, przygotuj czyste dane i traktuj timeout jako sygnał do diagnozy, nie jako rozwiązanie. Wtedy Playwright zaczyna pracować dla zespołu, a nie przeciwko niemu. Zostaje jeszcze ostatnia rzecz, która często decyduje o sukcesie całego wdrożenia: plan utrzymania.

Co zaplanować, zanim testy trafią na produkcyjny pipeline

Największy zwrot z automatyzacji nie bierze się z liczby testów, tylko z jakości decyzji podjętych na początku. Ja zaczynałbym od kilku krytycznych ścieżek: logowanie, rejestracja, zakup, wyszukiwanie, kluczowe formularze albo wszystko to, bez czego zespół nie chce wypuszczać releasu. Dopiero potem rozbudowywałbym zestaw, kiedy widać już, jak zachowuje się aplikacja i gdzie pojawiają się koszty utrzymania.

• Ustal, które testy mają biec na każdym pull requescie, a które tylko nocą albo przed wydaniem.
• Przyjmij jedną konwencję dla `data-testid` i nazw locatorów, żeby selektory nie rozjeżdżały się między zespołami.
• Oddziel strategię danych testowych od samego scenariusza, bo inaczej każdy test zaczyna robić za setup, asercję i cleanup naraz.
• Wyznacz właściciela dla flaky testów i określ, po jakim czasie taki test trafia do naprawy albo kwarantanny.
• Mierz czas uruchomienia, liczbę niepowodzeń i powtarzalność błędów, bo bez tych danych trudno wiedzieć, czy zestaw rzeczywiście pomaga.

Jeżeli podejdziesz do tego pragmatycznie, Playwright staje się bardzo dobrym fundamentem dla automatyzacji testów webowych. Najlepiej działa tam, gdzie potrzeba stabilnych locatorów, dobrego debugowania i rozsądnego zakresu odpowiedzialności. To właśnie ten zestaw daje zespołowi realną kontrolę nad jakością, zamiast kolejnego narzędzia, które tylko ładnie wygląda w repozytorium.