AI + Playwright? Najpierw ogarnij fundamenty

AI napisze Ci test w 10 sekund. Pytanie brzmi: czy będziesz wiedział(-a), czy jest dobry? Kiedy pierwszy raz zobaczyłem, jak ktoś generuje scenariusz pod Playwrighta jednym promptem, pomyślałem - super, wreszcie mniej klikania, więcej myślenia. Po kilku tygodniach przeglądania takich repozytoriów entuzjazm trochę opadł. Testy były, pipeline w GitHub Actions się świecił na zielono, a mimo to regresja przechodziła bokiem. Problemem nie było AI. Problemem był brak fundamentów.

Największy mit, który teraz widzę u juniorów i części midów, brzmi: "AI pomoże mi wejść w automatyzację szybciej". To prawda, ale tylko częściowo. Ono przyspiesza pisanie kodu, nie rozumienie architektury testów ani mechaniki frameworka. Jeśli nie rozumiesz, co generujesz, skalujesz chaos - tylko szybciej niż kiedykolwiek. A w testach chaos mści się w najmniej wygodnym momencie, zwykle tuż przed wdrożeniem 😅

AI to junior developer bez kontekstu

Dobrze myśleć o AI jak o bardzo szybkim juniorze. Wykona polecenie, wygeneruje klasę, dorzuci asercje, czasem nawet zaproponuje strukturę pod Page Object Model. Tyle że ono nie zna Twojego produktu, nie czuje ryzyka i nie rozumie, które ścieżki są krytyczne biznesowo. Nie podejmie decyzji, czy dana funkcjonalność wymaga testu e2e, czy lepiej pokryć ją testem API. To nadal jest rola QA - inżyniera zapewnienia jakości, a nie operatora promptów.

W praktyce widzę to tak: AI wygeneruje Ci selektor. Ty musisz wiedzieć, czy jest stabilny. AI doda waitForTimeout. Ty musisz wiedzieć, że to proszenie się o flaky test. AI stworzy pięć podobnych testów z powielonym kodem. Ty powinieneś zapytać, czy to nie moment na refaktoryzację i wyciągnięcie wspólnej logiki do klasy bazowej. Bez tej świadomości automatyzacja zaczyna przypominać losowe klikanie - tylko że zapisane w TypeScripcie.

Podstawy programowania - bez tego nie ruszaj

Jeśli zaczynasz używać AI w automatyzacji, a nie czujesz się pewnie z podstawami programowania, to zatrzymaj się na chwilę. Zmienne, funkcje, struktury danych, obsługa błędów, asynchroniczność - to nie są akademickie tematy. W Playwright wszystko jest asynchroniczne, a brak zrozumienia await to prosta droga do testów, które "czasem" przechodzą. A jeśli test pada "czasem", to nie problem AI. To sygnał, że gdzieś czai się race condition.

Asynchroniczność i race condition - czyli sytuacja, w której wynik zależy od kolejności wykonania operacji - to klasyka przy testach UI. Do tego dochodzą flaky testy, zależne od środowiska, danych czy czasu odpowiedzi API. AI tego nie wyeliminuje, jeśli nie rozumiesz, skąd się to bierze. Ono może co najwyżej dodać kolejny wait, który chwilowo zamaskuje problem. A zamaskowane problemy w CI/CD wracają szybciej, niż się spodziewasz.

OOP i Page Object Model - architektura ma znaczenie

Drugi fundament to programowanie obiektowe i wzorce. Page Object Model nie jest modą z tutoriali, tylko sposobem na utrzymanie porządku w projekcie testowym. Jeśli nie rozumiesz klas, enkapsulacji i odpowiedzialności obiektów, AI wygeneruje Ci testy z selektorami rozrzuconymi po całym repozytorium. Na początku działa. Po trzech sprintach masz duplikację, niespójne nazewnictwo i poprawki w dziesięciu plikach przy jednej zmianie w UI.

Dobrze zaprojektowany Page Object Model sprawia, że testy opisują zachowanie, a nie szczegóły implementacyjne. To Ty definiujesz standardy - strukturę folderów, konwencje nazewnicze, sposób budowania locatorów. AI może się do nich dostosować, jeśli je jasno opiszesz. Jeśli ich nie ma, będzie generować kod "jak leci". Standardy piszesz Ty. AI je tylko wykonuje.

Mechanika Playwrighta i praca z narzędziami

Kolejna rzecz to sama mechanika frameworka. Locatory, auto-waiting, praca z kontekstem przeglądarki, trace viewer, debugowanie - to są rzeczy, które trzeba rozumieć praktycznie. Playwright ma wbudowane mechanizmy oczekiwania na elementy, ale jeśli zaczniesz je nadpisywać ręcznymi timeoutami, szybko wpadniesz w spiralę niestabilności. AI często generuje kod "na skróty", bo statystycznie to działa. Ale w Twoim projekcie może nie działać.

Do tego dochodzi integracja z CI/CD, raportowanie, retry, tagowanie testów pod smoke czy regresję. Automatyzacja testów to nie tylko pliki .spec.ts. To cały proces jakościowy, który zaczyna się na refinementach, a kończy na wdrożeniu na produkcję. Jeśli traktujesz AI jako generator testów e2e bez szerszego kontekstu, łatwo odwrócić piramidę testów i oprzeć wszystko na najdroższym poziomie. A to już prosta droga do wolnych pipeline’ów i frustracji zespołu.

Przyspieszanie chaosu albo świadome wzmocnienie

Widziałem projekty, w których AI realnie pomogło. Zespół miał ustalone standardy, przemyślaną architekturę, jasno zdefiniowane Definition of Done i świadomość ryzyka. W takim środowisku AI przyspiesza pisanie boilerplate’u, pomaga w refaktoryzacji, podpowiada brakujące scenariusze. To jest prawdziwe shift-left - jakość od początku, z użyciem narzędzi, które skracają czas feedbacku.

Widziałem też projekty, gdzie AI wpadło do repozytorium bez zasad. Efekt? Setki testów e2e, brak spójności, flaky testy blokujące release i nikt nie wie, które scenariusze są naprawdę krytyczne. AI nie uratuje Twojej automatyzacji, jeśli nie znasz podstaw. Ono je tylko obnaży - bardzo szybko i bardzo boleśnie.

QA to architekt jakości, nie operator promptów

Na koniec najważniejsze. QA to nie osoba od klikania ani od generowania testów z prompta. To inżynier zapewnienia jakości, który rozumie ryzyko, architekturę testów, CI/CD i konsekwencje błędów na produkcji. Generowanie testu to jedno. Zaprojektowanie strategii testów - co, gdzie i na jakim poziomie testować - to zupełnie inna liga.

Jeśli chcesz używać AI w Playwrightcie świadomie, zacznij od fundamentów: programowanie, OOP, mechanika frameworka, zrozumienie flaky testów i race conditions, sensowna architektura z Page Object Model. Wtedy AI stanie się wzmacniaczem Twoich kompetencji. Bez tego będzie tylko bardzo szybkim generatorem problemów.

Polecane wpisy:

Sprawdź też moje social media: