Playwright UI w praktyce: lokatory, konsola i network

Co zrobimy w tej lekcji?

W tej lekcji poznasz narzędzia w Playwright UI, które pomagają podczas pisania i analizowania testów.

Skupimy się na lokator pickerze, czyli narzędziu do wybierania elementów na stronie, oraz na zakładkach console i network, które pomagają zrozumieć, co dzieje się w aplikacji podczas działania testów.

To będzie praktyczna lekcja, która przygotuje Cię do pisania pierwszego własnego testu w kolejnej części kursu.

A dokładniej:

  • Wyjaśnimy, czym jest lokator
  • Użyjemy lokator pickera
  • Wybierzemy kilka elementów z aplikacji
  • Porównamy podstawowe typy lokatorów
  • Sprawdzimy konsolę
  • Sprawdzimy zakładkę network
  • Wykorzystamy AI do analizy lokatorów i komunikatów

Przydatne linki

Krok 1: Uruchomienie Playwright UI

Ta komenda uruchamia Playwright w trybie UI:

npx playwright test --ui

W poprzedniej lekcji używaliśmy UI mode do uruchamiania testów i analizowania ich kroków. W tej lekcji wykorzystamy dodatkowe narzędzia dostępne w interfejsie: lokator picker, console i network.

Krok 2: Czym jest lokator?

Lokator to sposób, w jaki Playwright wskazuje konkretny element na stronie.

Przykładowo, jeśli test ma kliknąć przycisk, musi wiedzieć, który przycisk wybrać. Do tego służy właśnie lokator.

Lokator może wskazywać między innymi:

  • przycisk,
  • link,
  • pole tekstowe,
  • checkbox,
  • nagłówek,
  • komunikat na stronie.

Przykład:

page.getByRole('button', { name: 'Zaloguj' })

Ten lokator szuka przycisku o nazwie Zaloguj.

Inny przykład:

page.getByText('Dodaj produkt')

Ten lokator szuka elementu z widocznym tekstem Dodaj produkt.

Można też spotkać lokatory oparte o selektory CSS:

page.locator('.login-button')

Na tym etapie wystarczy zrozumieć, że lokator to “wskazanie elementu”, z którym test ma wykonać akcję.

Krok 3: Lokator picker

Lokator picker pomaga wybrać element na stronie i wygenerować dla niego lokator.

Dzięki temu nie musisz zgadywać, jak wskazać dany przycisk, pole tekstowe albo link. Możesz kliknąć element w aplikacji i zobaczyć propozycję lokatora wygenerowaną przez Playwright.

Warto jednak pamiętać, że lokator picker daje propozycję. Nie zawsze będzie to najlepszy możliwy lokator. W kolejnych lekcjach omówimy, jak wybierać lokatory, które są czytelne i stabilne.

Krok 4: Podstawowe typy lokatorów

W Playwright możesz spotkać różne typy lokatorów.

getByRole

page.getByRole('button', { name: 'Zaloguj' })

Ten typ lokatora jest często dobrym wyborem dla elementów interaktywnych, np. przycisków czy linków. Jest czytelny i dobrze odzwierciedla sposób, w jaki użytkownik korzysta ze strony.

getByText

page.getByText('Zaloguj')

Ten lokator wyszukuje element po widocznym tekście. Może być przydatny przy nagłówkach, komunikatach lub linkach.

Trzeba jednak uważać, jeśli ten sam tekst występuje na stronie wiele razy.

lokator

page.locator('.login-button')

Ten zapis pozwala użyć selektora CSS. Może być przydatny, ale bywa mniej czytelny i mniej stabilny, jeśli opiera się na klasach technicznych, które często się zmieniają.

Krok 5: Konsola

W Playwright UI możesz podejrzeć konsolę przeglądarki.

Konsola pokazuje między innymi:

  • błędy JavaScript,
  • ostrzeżenia,
  • logi aplikacji,
  • komunikaty z przeglądarki.

To ważne, ponieważ czasami test nie przechodzi nie dlatego, że test jest źle napisany, ale dlatego, że aplikacja ma błąd.

Jeśli widzisz w konsoli błędy, warto je sprawdzić i zastanowić się, czy mogą wpływać na zachowanie testu.

Krok 6: Network

Zakładka network pokazuje komunikację aplikacji z backendem.

Możesz tam sprawdzić:

  • jakie requesty wysyła aplikacja,
  • czy dane zostały pobrane,
  • jakie statusy mają odpowiedzi,
  • czy pojawiły się błędy API.

Najprostsze statusy, które warto kojarzyć:

  • 200 — request zakończony sukcesem,
  • 404 — zasób nie został znaleziony,
  • 500 — błąd po stronie serwera.

Network przydaje się szczególnie wtedy, gdy aplikacja nie pokazuje danych, formularz nie działa albo test nie przechodzi, mimo że kod testu wygląda poprawnie.

Krok 7: AI jako wsparcie

AI możesz wykorzystać do analizy lokatorów, błędów z konsoli i statusów requestów.

Przykładowe prompty:

Wyjaśnij początkującemu, co robi ten lokator Playwright:

[wklej lokator]
Czy ten lokator jest dobry i stabilny w Playwright?
Podaj jego zalety, wady i ewentualnie lepszą alternatywę:

[wklej lokator]
Porównaj te lokatory i powiedz, który będzie lepszy dla testów Playwright:

page.getByRole(‘button’, { name: ‘Zaloguj’ })
page.locator(‘.login-button’)
W konsoli przeglądarki widzę taki błąd:

[wklej błąd]

Wyjaśnij, co może oznaczać i czy może wpływać na test Playwright.
W zakładce network widzę request ze statusem 500.
Wyjaśnij początkującemu, co to oznacza i co warto sprawdzić dalej.

Im więcej kontekstu podasz AI, tym lepszą odpowiedź dostaniesz. Warto wkleić nie tylko sam błąd, ale też informację, co próbujesz zrobić i co widzisz w aplikacji.

Zadania dla Ciebie

  1. Uruchom aplikację Rolnopol lokalnie:
npm run start
  1. Uruchom Playwright UI:
npx playwright test --ui
  1. Otwórz lokator picker.
  2. Wybierz minimum 5 elementów aplikacji, np.:
  • przycisk,
  • link,
  • pole tekstowe,
  • nagłówek,
  • element listy.
  1. Skopiuj wygenerowane lokatory i porównaj je.
  2. Sprawdź zakładkę console.
  3. Sprawdź zakładkę network.
  4. Znajdź przykładowy request i sprawdź jego status.
  5. Skopiuj jeden lokator i poproś AI o ocenę, czy jest dobry.
  6. Zapytaj AI, co oznacza wybrany status requestu, np. 200, 404 albo 500.

Co dalej?

W kolejnej lekcji napiszemy pierwszy własny test Playwright.

Będziemy pracować z:

  • page.goto,
  • click,
  • fill,
  • expect,
  • lokatorami,
  • podstawowym async/await.

Celem będzie stworzenie testu, który wykonuje realne akcje w aplikacji Rolnopol i sprawdza ich rezultat.


Radosław Wasik
QA Tech Lead, Content Creator
profil na LinkedIn

QA Tech Lead z wieloletnim doświadczeniem w testach manualnych i automatyzacji. Specjalizuje się w Playwright (JS/TS) oraz projektowaniu skalowalnych frameworków testowych, które wspierają stabilne procesy CI/CD.

Na co dzień prowadzi zespoły QA - wyznacza cele, planuje działania, wspiera rozwój testerów i usprawnia strategie testowe oraz procesy releasowe we współpracy z developerami i biznesem.

Przeprowadza również szkolenia dla QA, skupiając się na praktycznej automatyzacji testów, dobrych praktykach (m.in. Page Object Model), pracy z narzędziami oraz budowaniu podejścia jakościowego w zespołach produktowych. Aktywnie dzieli się wiedzą w internecie: na Instagramie @radwasik publikuje krótkie, przystępne materiały o testowaniu, automatyzacji i AI, a na blogu rwasik.pl rozwija tematy w formie artykułów, poradników i case studies z codziennej pracy.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *