Migracje z Selenium i Selenide do Playwrighta prowadzę zawodowo od kilku lat i większość zaczyna się podobnie: suita ma kilkaset testów, co trzeci build na CI jest czerwony bez związku z aplikacją, a zespół odkłada zmianę, bo „nie ma kiedy”. Ten artykuł zakłada, że wybór narzędzia masz już za sobą, jeśli dopiero porównujesz oba frameworki, zacznij od tekstu Selenium czy Playwright, bo tutaj tego porównania nie powtarzam. Poniższa checklista to proces, który stosuję u klientów: siedem kroków, od audytu starej suity po usunięcie zależności Selenium z projektu.
Krok 1: Audyt testów i wybór strategii
Zanim powstanie pierwsza linijka kodu w Playwrighcie, policz i oceń to, co masz. W suitach, które audytuję, 15–30% testów nadaje się do kasacji: sprawdzają usunięte funkcje albo dublują inne scenariusze. Przepisywanie ich do nowego frameworka to praca bez zwrotu.
- Przejrzyj pokrycie: oznacz testy chroniące krytyczne ścieżki biznesowe, testy niestabilne (wraz z powodem niestabilności) i te do usunięcia.
- Wybierz strategię: podejście „wszystko naraz” widziałem dwa razy i oba podejścia zamroziły development na tygodnie. Sprawdza się model stopniowy: nowe testy od razu w Playwrighcie, stare partiami, zaczynając od najważniejszych lub najbardziej problematycznych.
- Ustal mierzalne cele: np. czas wykonania suity krótszy o 40%, mniej niż 2% testów niestabilnych. Bez liczb nie ocenisz, czy migracja się udała.
Krok 2: Środowisko i zespół
Migracja wywraca nie tylko kod, ale i nawyki, więc przygotuj jedno i drugie.
- Zainicjuj projekt (
npm init playwright@latest), wybierz TypeScript, ustal strukturę katalogów i raportowanie, zanim dołączy reszta zespołu. - Podepnij testy pod CI w pierwszym tygodniu. Problemy konfiguracyjne (przeglądarki w kontenerze, artefakty, uprawnienia) taniej wyłapać na pięciu testach niż na dwustu.
- Zrób zespołowi warsztat z różnic: model lokatorów, auto-wait, konteksty przeglądarki, praca z API. Ustalcie konwencję lokatorów; u mnie standardem jest
getByRolezamiast selektorów CSS i XPath, bo przeżywa zmiany w markupie.
Krok 3: Najpierw fundamenty frameworka, potem testy
Częsty błąd: zespół rzuca się na przepisywanie testów, a page objecty i helpery dopisuje w biegu. Rób odwrotnie. Wzorzec Page Object koncepcyjnie przenosi się jeden do jednego, zmienia się implementacja: zamiast WebDriver i WebElement pracujesz na obiektach Page i Locator. To dobry moment na poprawę selektorów:
// Selenide
private SelenideElement loginButton = $("button[type='submit']");
// Playwright
readonly loginButton = this.page.getByRole('button', { name: 'Zaloguj' });Zarządzanie przeglądarkami masz wbudowane: Chromium, Firefoksa i WebKita konfigurujesz w pliku playwright.config.ts, a WebDriverManager wylatuje z projektu. Przenieś też helpery, logowanie, obsługę ciasteczek, generowanie danych testowych. Część z nich uprościsz, bo np. locator.fill() sam czyści pole przed wpisaniem tekstu. Jeśli Twój obecny framework stoi na Selenide, jego architekturę opisałem we wprowadzeniu do Selenide i Selenium; z tego zestawienia łatwo zbudujesz mapę „co czym zastąpić”.
Krok 4: Pierwsza partia testów
Na start wybierz małą, wartościową grupę: testy dymne albo dwa–trzy proste scenariusze end-to-end. Celem tego etapu jest doświadczenie, nie liczby w raporcie. Zespół zderzy się z pierwszymi realnymi problemami i nauczy się myśleć po playwrightowemu, zamiast tłumaczyć kod słowo w słowo. Spisujcie napotkane pułapki razem z rozwiązaniami, ten dokument posłuży za przewodnik osobom, które dołączą do migracji później.
Krok 5: Auto-wait i mockowanie sieci
Największa zmiana mentalna dotyczy czekania. Playwright przed każdą akcją sam sprawdza, czy element jest widoczny, stabilny i gotowy na interakcję, więc większość konstrukcji typu WebDriverWait kasujesz bez zamiennika. Jawne czekanie zostaje w niszowych sytuacjach, np. waitForResponse, gdy test ma poczekać na konkretne żądanie API.
Drugą dużą nowość daje page.route(): przechwytywanie ruchu sieciowego bez zewnętrznych narzędzi. Używam tego do izolowania frontendu od backendu, do symulowania błędów serwera (jak aplikacja reaguje na status 500?) i do podmiany wolnych zapytań na statyczne dane, co potrafi skrócić pojedynczy test o kilkanaście sekund.
Krok 6: Optymalizacja i sprzątanie nawyków
- Trace Viewer: włącz zapisywanie śladów. Dostajesz zrzut ekranu z każdej akcji, logi konsoli, ruch sieciowy i oś czasu. W Selenium na analizę niestabilnego testu traciłem czasem pół dnia; z trace’em schodzi mi to w kilka minut.
- Równoległość: Playwright uruchamia testy równolegle bez dodatkowej infrastruktury. Dobór liczby
workersdo maszyny CI to najtańszy sposób na skrócenie całej suity. - Refaktoryzacja: przejrzyj zmigrowany kod pod kątem starych nawyków. Najczęstszy, jaki wyłapuję w review:
Thread.sleepprzetłumaczony mechanicznie nawaitForTimeout. Ten sam problem, nowe opakowanie.
Krok 7: Wycofanie Selenium
Przez sprint lub dwa uruchamiaj obie suity równolegle na CI i porównuj, co łapią. Dopiero gdy nowa suita przez ten okres wykrywa te same regresje co stara, usuń zależności: Selenium, Selenide, WebDriverManagera i cały powiązany kod. Ten krok zespoły odkładają najchętniej, a im dłużej utrzymujesz dwa stacki, tym pewniej ktoś dopisze nowy test w starym i migracja rozjedzie się na kolejne kwartały.
Ile to trwa i od czego zacząć
Suita 200–400 testów to w moich projektach zwykle dwa–trzy miesiące pracy przeplatanej z bieżącym developmentem, przy czym pierwsze zielone buildy w Playwrighcie pojawiają się po tygodniu, dwóch. Najlepszy pierwszy ruch na jutro: audyt z kroku 1, bo lista testów do skasowania od razu zmniejsza skalę całego przedsięwzięcia. A jeśli chcesz, żeby ktoś przeszedł tę checklistę razem z Twoim zespołem, odezwij się, migracje frameworków testowych to dokładnie ten rodzaj pracy, który wykonuję jako QA Sensei.