Im dłużej pracuję z Playwright, tym bardziej widzę, że największą różnicę robią nie jakieś „magiczne” komendy, tylko małe funkcje i rozwiązania, które codziennie oszczędzają czas.
Na początku człowiek skupia się głównie na tym, żeby test w ogóle działał. Później zaczyna się walka z:
- flaky testami,
- debugowaniem,
- powtarzaniem tego samego setupu,
- wolnymi pipeline’ami,
- chaosem w frameworku.
I właśnie wtedy zaczyna się doceniać rzeczy, które naprawdę ułatwiają życie.
Poniżej 5 funkcji w Playwright, z których korzystam najczęściej i które realnie przyspieszają mi pracę praktycznie każdego dnia.
1. Trace Viewer
To jest funkcja, bez której dziś ciężko byłoby mi pracować przy większych projektach.
Kiedyś debugowanie testów wyglądało tak, że:
- odpalałem test kilka razy,
- dodawałem console.logi,
- robiłem screenshoty,
- próbowałem zgadnąć, co właściwie się wydarzyło.
Szczególnie na CI/CD było to irytujące, bo lokalnie test działał, a pipeline już niekoniecznie.
I właśnie tutaj wchodzi Trace Viewer.
Playwright zapisuje cały przebieg testu, dzięki czemu mogę później krok po kroku zobaczyć:
- co kliknął test,
- co było widoczne,
- jakie requesty poszły,
- jakie były odpowiedzi API,
- w którym miejscu pojawił się problem,
- jak wyglądała aplikacja dokładnie w momencie błędu.
Najbardziej lubię to, że można praktycznie „odtworzyć” cały test jak nagranie.
Przy flaky testach to jest złoto.
Bardzo często problem okazuje się banalny — np. element ładuje się sekundę dłużej albo backend zwrócił wolniejszą odpowiedź. Bez trace’a człowiek często tylko zgaduje.
2. Auto waiting
To jest jedna z tych rzeczy, które docenia się dopiero po przejściu z innych frameworków.
W wielu starszych projektach nadal można znaleźć coś takiego:
await page.waitForTimeout(5000)I szczerze mówiąc — to zazwyczaj prędzej czy później kończy się problemami.
Bo:
- raz aplikacja załaduje się szybciej,
- raz wolniej,
- raz pipeline jest obciążony,
- raz środowisko działa idealnie.
I później zaczyna się loteria.
Playwright bardzo dużo rzeczy obsługuje automatycznie.
Framework sam potrafi poczekać np. aż:
- element będzie widoczny,
- będzie możliwe kliknięcie,
- zakończy się animacja,
- element przestanie się przesuwać.
Dzięki temu testy są po prostu stabilniejsze.
Oczywiście nadal zdarzają się sytuacje, gdzie trzeba użyć explicit waitów, ale odkąd przestałem używać timeoutów „na ślepo”, liczba problemów naprawdę mocno mi spadła.
I co najważniejsze — kod wygląda dużo czyściej.
3. storageState
Jeżeli ktoś codziennie wykonuje login od nowa w każdym teście, to naprawdę warto zainteresować się storageState.
W moich pierwszych projektach ogrom czasu schodziło na:
- logowanie użytkownika,
- wpisywanie danych,
- przechodzenie przez MFA,
- przygotowanie sesji,
- odpalanie tych samych kroków przed każdym testem.
Przy większej liczbie testów robiło się to po prostu męczące i niepotrzebnie wydłużało execution time.
Dziś robię login raz.
Później zapisuję stan sesji użytkownika i kolejne testy startują już jako zalogowany użytkownik.
Różnica jest ogromna.
Testy:
- działają szybciej,
- są bardziej stabilne,
- framework wygląda bardziej profesjonalnie,
- i dużo łatwiej pracuje się z różnymi rolami użytkowników.
Przy większych projektach naprawdę ciężko później wrócić do starego podejścia.
4. UI Mode
Na początku myślałem, że UI Mode to bardziej taki „gadżet”.
Ale po kilku tygodniach używania zacząłem korzystać z tego praktycznie codziennie.
Najbardziej podoba mi się to, że mogę bardzo szybko:
- odpalać pojedyncze testy,
- debugować konkretne scenariusze,
- sprawdzać locatory,
- analizować kroki testu,
- poprawiać testy bez ciągłego wpisywania komend w terminalu.
Przy małym projekcie może nie robi to aż takiej różnicy.
Ale kiedy framework robi się większy i testów zaczyna przybywać, wygoda pracy naprawdę mocno wzrasta.
To jest jedna z tych funkcji, które może nie wyglądają spektakularnie na prezentacjach, ale w codziennej pracy oszczędzają mnóstwo czasu i nerwów.
5. Fixtures
O fixture’ach pisałem już osobny wpis, ale nadal uważam, że to jedna z najbardziej niedocenianych rzeczy w Playwright.
Na początku wiele osób wrzuca wszystko bezpośrednio do testów:
- logowanie,
- setup,
- tworzenie danych,
- konfigurację użytkownika,
- przygotowanie środowiska.
I po kilku tygodniach robi się chaos.
Kod zaczyna się powtarzać.
Testy robią się długie.
Coraz trudniej coś utrzymać.
Fixtures pomagają to uporządkować.
Dzięki nim:
- testy są krótsze,
- kod jest czytelniejszy,
- framework łatwiej rozwijać,
- łatwiej pracować zespołowo,
- i dużo szybciej dodaje się nowe scenariusze.
U mnie moment przejścia na fixtures był jednym z tych momentów, gdzie framework zaczął wyglądać bardziej jak profesjonalny projekt, a nie zbiór przypadkowych testów.
I szczerze mówiąc — dziś trudno byłoby mi wrócić do starego podejścia.
Podsumowanie
Im więcej pracuję z Playwrightem, tym bardziej widzę, że największą wartością nie są pojedyncze komendy, tylko funkcje, które realnie poprawiają codzienną pracę.
Trace Viewer skraca debugowanie.
Auto waiting ogranicza flaky testy.
storageState przyspiesza testy.
UI Mode poprawia komfort pracy.
Fixtures pomagają utrzymać porządek w frameworku.
I właśnie takie rzeczy robią największą różnicę przy większych projektach.
Bo finalnie mniej czasu spędzasz na walce z frameworkiem, a więcej na faktycznym testowaniu aplikacji.
