Debugowanie i testy w Playwright? Zalety i różne sposoby
Language
date
Sep 4, 2024
slug
playwright-debug
author
status
Public
tags
Playwright
TypeScript
Porady
Automatyzacja
Narzędzia
summary
Zobacz, dlaczego debugowanie jest ważne i jakie techniki można zastosować w testach z Playwright
type
Post
thumbnail
updatedAt
Sep 10, 2024 04:54 AM
category
👨🏫 Porady
Zacznijmy od technicznej definicji:
Debugowanie to proces analizy kodu, znajdowania i naprawiania błędów w kodzie.
Jest to kluczowy element w tworzeniu oprogramowania, ponieważ nawet najlepiej napisany kod może zawierać błędy.
A kiedy mówimy o testach automatycznych, debugowanie staje się jeszcze ważniejsze!
Od poprawności testów może zależeć jakość i powodzenie całego projektu.
W tym wpisie omówimy, dlaczego debugowanie jest tak istotne.
Przedstawimy też różne techniki debugowania testów automatycznych (głównie tych, opartych o Playwright).
💡
W najbliższych dniach organizujemy webinar “Testerze! Zacznij debugować testy!”:
📅 11 września (środa)
⏰ 20:00-21:30
📺 na naszym kanale YouTube
Opowiemy tam o różnych technikach i sposobach analizy błędów w testach😉
Wszystkie informacje i linki o webinarze znajdziesz na naszej stronie:
🔗https://jaktestowac.pl/debug
Dlaczego debugowanie jest ważne?
Przy pisaniu albo uruchamianiu testów automatycznych, testy mogą nie działać zgodnie z oczekiwaniami.
Czyli - mogą pojawiać się w nich różne błędy.
Pamiętajmy o tym, że problemy mogą być zarówno wewnętrzne (w naszym kodzie) jak i zewnętrzne:
zmiany w interfejsie użytkownika (UI/GUI)
zmiany w backendzie (REST API)
niewłaściwych danych testowych
błędy w aplikacji
zmiany konfiguracji środowiska
wiele innych.
Debugowanie pozwala łatwiej zidentyfikować przyczynę problemu.
A tym samym - możemy go szybciej naprawić.
Techniki debugowania w Playwright
Zatrzymanie testu poprzez page.pause()
Zatrzymanie testu w określonym miejscu jest przydatne, gdy chcemy skupić się na konkretnym fragmencie kodu, który może być źródłem problemu. Można to zrobić poprzez dodanie do kodu instrukcji await page.pause().
Spowoduje ona zatrzymanie testu w danym miejscu i dodatkowo otworzy interfejs debugowania (Playwright Inspector). To pozwala na ręczne wykonanie kolejnych kroków testu, analizowanie stanu aplikacji oraz modyfikowanie kodu na bieżąco.
✅ Plusy:
Dokładna kontrola - pozwala na skupienie się na konkretnym fragmencie kodu.
Łatwość użycia - wymaga tylko dodania jednej linii kodu (await page.pause()), aby zatrzymać test.
❌ Minusy:
Brak automatyzacji - wymaga manualnej pracy i ręcznego wznawiania testu, co może być uciążliwe przy dużej liczbie miejsc do sprawdzenia.
Zaśmiecanie kodu - łatwo o rozpropagowanie kodu z takimi wpisami
Zastosowanie breakpointów z wtyczka VSCode do Playwright
Breakpointy to standardowa technika debugowania, którą można również wykorzystać w testach Playwright.
Ustawienie breakpointu w kodzie pozwala zatrzymać wykonywanie testu w wybranym miejscu. Dzięki temu możemy dokładnie przeanalizować stan aplikacji, wartości zmiennych oraz sprawdzenie, czy kod działa zgodnie z oczekiwaniami.
Można je ustawiać w edytorze kodu, takim jak VS Code, korzystając z narzędzi do debugowania JavaScript.
Dzięki temu testy zostaną uruchomione np. wraz z przeglądarka i domyślna konfiguracją.
💡
Podczas debugowania między poszczególnymi akcjami upływa więcej czasu gdy przechodzimy step by step po kodzie.
Dodatkowo czas debugu zwiększa się gdy wykonujemy analizę wartości zmiennych.
Tym samym może się zdarzyć, że test, który normalnie nie przechodził, podczas debugowania zakończy się powodzeniem.
✅ Plusy:
Precyzyjność - pozwala na precyzyjne zatrzymanie kodu w określonym miejscu i analizę stanu zmiennych.
Narzędzia w IDE - edytory (VS Code) oferują bogaty zestaw narzędzi do debugowania kodu.
Integracja z przeglądarką - możemy w czasie rzeczywistym śledzić zachowanie w podczas testu
❌ Minusy:
Złożoność - może być trudne do użycia dla osób, które nie są zaznajomione z kodem lub narzędziami debugującymi w IDE.
Potrzeba konfiguracji - czasem może wymagać odpowiedniego skonfigurowania środowiska i edytora kodu.
Czasem mogą wystąpić problemy z gubieniem się debuggera i podczas debug wpadniemy w pliki biblioteki Playwright
💡
Podczas debuggingu w widoku konsoli w zakładce DEBUG CONSOLE możesz wykonywać różne polecenia aby zweryfikować ich wynik.
Podgląd logów (console.log)
Wykorzystanie console.log to prosty, ale czasem skuteczny sposób debugowania.
Dodanie console.log w odpowiednich miejscach kodu pozwala na śledzenie wartości zmiennych czy wyników funkcji. Dzięki temu możemy szybko zidentyfikować, gdzie występuje problem, a także jakie wartości mogą być przyczyną nieoczekiwanego zachowania testu.
Jest to szybki i prosty sposób na analizę kodu. Jednak jest on również zazwyczaj niezalecany, aby pozostawiać taką konstrukcję w kodzie w repozytorium.
💡
Warto ustawić w narzędziu do statycznej analizy kodu (np. ESLint) reguły, które będą nam wyświetlać ostrzeżenia po użyciu console.log
Dodatkowo można skorzystać z paczek, które zabezpieczą nas przed wypuszczeniem kodu z takimi wpisami do repozytorium (np. Husky)
Dzięki temu łatwiej będzie nam usunąć wszystkie użycia tej konstrukcji z naszego kodu.
✅ Plusy:
Szybki - stosunkowo szybki sposób na zidentyfikowanie podstawowych problemów.
Łatwy - wystarczy dodać kilka linijek kodu, aby uzyskać przydatne informacje o stanie aplikacji.
❌ Minusy:
Czasochłonny - logi mogą nie dostarczać pełnych informacji i każdorazowo musimy uruchamiać dany test aby wypisać informacje na konsoli.
Zaśmiecanie kodu - korzystanie z console.log może zaśmiecać kod i utrudniać jego czytelność.
💡
Konfiguracja ostrzegająca i niedopuszczająca dodanie np. console.log do repozytorium kodu to dość złożony temat.
Reguły takie jak zabezpieczenie przed używaniem console.log oraz inne zasady dotyczące statycznej analizy kodu szczegółowo opisujemy w Programie Automatyzacji z Playwright🔗https://jaktestowac.pl/playwright/
💡
Jeśli widzisz potrzebę logowania wielu treści w projekcie zastosuj dedykowane rozwiązanie w postaci loggera. Możesz użyć na przykład biblioteki Winston https://github.com/winstonjs/winston
Analiza plików Trace
Playwright umożliwia generowanie plików Trace, które zawierają szczegółowe informacje o każdym kroku testu, w tym o stanie aplikacji, wykonywanych operacjach oraz ewentualnych błędach. Można je np. otworzyć w narzędziu Trace Viewer.
Pliki te można przeanalizować, aby znaleźć dokładny moment, w którym wystąpił problem. Narzędzie trace viewer umożliwia przeglądanie tych plików w interaktywny sposób, co znacznie ułatwia diagnozowanie złożonych problemów.
Możemy śledzić poszczególne kroki zarówno dla warstwy UI i REST API.
Trace Viewer ustawimy przechodząc do widoku Testing i oznaczając opcję Show trace viewer:
Teraz przy każdym teście otrzymamy widok Trace Viewer.
Warto w konfiguracji Playwright w playwright.config.ts podczas debugowania włączyć stałe gromadzenie Trace:
Szczegółowość - dostarcza bardzo szczegółowych informacji (screeny, logi, komunikację po API) o każdym kroku testu, co pomaga w zidentyfikowaniu trudnych do wykrycia błędów.
Historia wykonania - umożliwia prześledzenie całej historii wykonania testu, co może być pomocne przy analizie problemów. Mamy wygodny widok stanu przed, w czasie i po akcji na stronie.
Udostępnianie - tego typu plik możemy łatwo udostępnić jako informację na temat buga lub artefakt w procesie ciągłej integracji, bez potrzeby odtwarzania kroków doprowadzających do błędu
Integracja - Trace może można automatycznie dołączyć do raportu z testu dzięki czemu łatwo powiązać błędy w kodzie z danym Trace
❌ Minusy:
Złożoność analizy - analiza plików trace może być czasem skomplikowana przez dużo informacji, funkcji i różnorodnych zakładek.
Możesz łatwo otworzyć ten plik wrzucając go do aplikacji odtwarzającej Trace:
🔗https://trace.playwright.dev
Dzięki temu wystarczy, że podeślesz komuś zip z Trace i bez potrzeby instalacji paczek z łatwością można podglądać wyniki.
⚠️ Pamiętaj o bezpieczeństwie i nigdy nie dziel się plikami poufnymi z nieautoryzowanymi użytkownikami lub stronami
💡
Chcesz szybko przeglądać pliki Trace? Wystarczy, że dodasz naszą autorską wtyczkę 🔗Playwright Helpers i przejdziesz do opcji SHOW TRACE!
Playwright domyślnie uruchamia testy w trybie headless, czyli bez interfejsu graficznego.
Jednak w trybie debugowania często korzysta się z trybu headed, który uruchamia przeglądarkę z interfejsem graficznym. Pozwala to zobaczyć, jak zachowuje się testowana aplikacja podczas testów. Może to pomóc w zidentyfikowaniu błędów związanych z renderowaniem, interakcjami użytkownika, czy problemami z ładowaniem elementów na stronie.
Tryb headed jest domyślnie włączany gdy rozpoczynamy debug z VSCode i wtyczką Playwright. Aby uruchomić testy z trybem headed bez debugowania należy włączyć tę opcję w zakładce TESTING:
✅ Plusy:
Bezpośrednia obserwacja - tryb headed pozwala na obserwowanie przebiegu testu w rzeczywistości, co może pomóc w zidentyfikowaniu problemów wizualnych.
Szybsze testy - tryb headless umożliwia wykonywanie testów bez zajęcia ekranu/przeglądarki, dzięki temu równocześnie możemy zajmować się innymi zadaniami.
❌ Minusy:
Brak widoczności przeglądarki wtrybie headless - nie pozwala na bezpośrednią obserwację, co może utrudniać debugowanie.
Wyniki testów dla headless i headed mogą się różnić, ze względu na różnice w czasie wykonywanych testów w danym trybie.
💡
Dana wersja przeglądarki Chromium jest ściśle powiązana z konkretną wersją Playwright.
Oznacza to, że z Playwright, w danym wydaniu mamy do dyspozycji jedną i dokładnie określoną wersję Chromium.
Nieraz utrudnia to debug problemu, który jest zależny od wersji przeglądarki (np. najnowszego wydania Chrome).
W takim przypadku pozostaje nam zaczekać na aktualizację paczki Playwright albo użycie poprzedniej wersji Paczki jeśli tam nie występował błąd.
UI Mode
Tryb UI Mode w Playwright to interaktywne środowisko do uruchamiania i debugowania testów.
UI Mode pozwala na wizualne śledzenie przebiegu testów, przeglądanie zrzutów ekranu, logów, a także nawigowanie po testach. Jest to szczególnie przydatne, gdy chcemy szybko zidentyfikować problemy w konkretnych przypadkach testowych i zobaczyć, jak zachowuje się aplikacja w czasie rzeczywistym.
Aby uruchomić UI Mode wystarczy w folderze projektu wykonać polecenie: npx playwright test --ui .
Teraz każde wykonanie testu będzie się odbywało z podglądem Trace.
💡
Nie musisz pamiętać powyższego polecenia. Wystarczy, że dodasz naszą autorską wtyczkę Playwright Helpers i z łatwością wyszukasz to polecenie!
Warto pamiętać o zaznaczeniu odpowiednich projektów aby testy zależne mogły uzyskać odpowiednie przygotowanie.
✅ Plusy:
Łatwość użycia - intuicyjny interfejs graficzny ułatwia debugowanie testów nawet mniej doświadczonym użytkownikom.
Kompleksowe narzędzie - oferuje zintegrowane narzędzia do analizy, w tym logi, zrzuty ekranu, komunikację REST API i nawigację po testach.
❌ Minusy:
Złożoność - może być przytłaczający dla początkujących użytkowników z powodu ilości dostępnych funkcji.
Nieoczywiste uruchomienie w Debug aby połączyć z debuggerem w VS Code
Ograniczenia związane z informacjami np. o ruchu sieciowym (w porównaniu do Chrome Dev Tool)
Ograniczenia związane z logowaniem stanu ustawianego w Global Setup wspieranego przez Playwright.
💡
Opisywane wcześniej console.log możesz podglądać w UI Mode w widoku OUTPUT:
💡
W Playwright trudno połączyć klasyczne debugowanie z UI Mode, aby mieć podgląd Trace i jednocześnie korzystać z brakepointów. Tę technikę opisujemy tutaj: https://playwright.info/debug-playwright-trace
Nasza wtyczka Playwright Helpers pozwala na automatyczne ustawienie tej opcji przy uruchamianiu testów 😉
Więcej o niej poczytasz na dedykowanej stronie:
🔗https://jaktestowac.pl/vs-code-playwright/
✅ Plusy:
Dodatkowe informacje - Playwright staje się bardziej “gadatliwy” a tym samym mamy wgląd w poszczególne akcje, które są wykonywane przez to narzędzie.
❌ Minusy:
Przydatność może być niewielka - logi zawierają różne niskopoziomowe i ogólne informacje, które w wielu przypadkach podczas testów mogą być mało przydatne w analizie błędów w teście (kod, skrypty czy interakcje z elementami)
Chrome Dev Tools
Chrome DevTools to zaawansowany zestaw narzędzi deweloperskich wbudowanych bezpośrednio w przeglądarkę Google Chrome.
Służy do debugowania, analizy kodu i analizy stron internetowych oraz aplikacji webowych. Jest to jedno z najpopularniejszych narzędzi wśród programistów i testerów, ponieważ oferuje szeroką gamę funkcji, które ułatwiają pracę nad front-endem i back-endem aplikacji.
Dev Tools uruchomisz zarówno w Chrome jak i w przeglądarce Chromium dostarczanej z Playwright.
Możesz np. zastosować skrót klawiszowego F12.
Najważniejsze zakładki:
Elements - przeglądanie wynikowego kodu testowanej strony
Console - konsola do wprowadzania poleceń (np. testowanie lokatorów)
Network - podgląd ruch sieciowego, z modyfikacją połączenia i szczegółowymi informacjami dla poszczególnych zapytań
Application - przeglądanie plików generowanych w wyniku pobierania strony
✅ Plusy:
Dostępność i cena - Chrome DevTools są wbudowane w przeglądarkę Google Chrome - są dostępne dla każdego za darmo, bez potrzeby instalacji dodatkowych narzędzi.
Mnogość funkcji - oferuje wiele funkcji, takich jak inspekcja DOM, edycja stylów CSS, debugowanie JavaScript, monitorowanie sieci, profilowanie wydajności, zarządzanie pamięcią i wiele więcej.
❌ Minusy:
Brak funkcji automatyzacji - Chrome DevTools skupia się na ręcznym debugowaniu i analizie aplikacji. Brakuje w nim funkcji związanych z automatyzacją testów lub skryptów, które mogą przyspieszyć pracę nad bardziej złożonymi zadaniami.
Krzywa uczenia się - pełne opanowanie zaawansowanych funkcji, takich jak śledzenie wydajności czy analiza pamięci, wymaga czasu i nauki
💡
Każde pojedyncze zapytanie wykonane przez testowaną stronę możesz zreprodukować przechodząc do wybranego requesta w zakładce Network.
Wystarczy kliknąć prawy przycisk myszki na wybranym request i wybierać opcje: Copy → Copy as fetch:
💡
Następnie w konsoli wystarczy wkleić zawartość schowka i wykonać ponownie request.
Można też użyć zawartości do porównania z tą którą generują testy automatyczne lub użyć do analizy błędów.
Pamiętaj aby w przypadku asynchronicznych wywołań dodać słowo kluczowe await przed wklejoną zawartością:
Grupa jest zamknięta - ale weryfikacja administratorów przebiega szybko i generalnie warto tam bywać 😎
Bonus: Obiekt playwright którego użyjesz w konsoli przeglądarki wywołanej przez Playwright
Admin facebookowej grupy Playwright Dev: Józef Szymala wspomniał również o takiej metodzie:
Za pomocą obiektu playwright możesz uzyskać wiele ciekawych informacji ma temat obiektu jak i podświetlić go w UI.
playwright.$(selector): podświetlenie pierwszego elementu
playwright.$$(selector): wszystkie elementy pasujące do selektora
playwright.locator(selector): jw
playwright.clear(): wyczyść zaznaczenia
playwright.selector(element): wygeneruj selektor
playwright.inspect(selector): sprawdzenie elementu
Podsumowanie
Za nami zaledwie wstęp do strategii debugowania 😉
Każda ze wspomnianych technik oferuje inne podejście do debugowania testów automatycznych.
Kluczem do skutecznego debugowania jest dobranie odpowiedniej techniki do konkretnego problemu, z jakim się mierzymy. Czasami wystarczy proste uruchomienie testu w trybie „headed”, a innym razem konieczne będzie dokładniejsze przeanalizowanie logów, wideo czy plików trace.
💡 Natomiast często rozwiązaniem jest kombinacja różnych technik.
Takie podejście pozwala na szybsze i efektywniejsze rozwiązywanie problemów przez wykorzystanie mocnych stron różnych podejść😉
💡
Webinar “Testerze! Zacznij debugować testy!” zorganizujemy:
📅 11 września (środa)
⏰ 20:00-21:30
📺 na naszym kanale YouTube
Wszystkie informacje i linki o webinarze znajdziesz na naszej stronie:
🔗https://jaktestowac.pl/debug
