📚 Podstawy Playwright

Dowiedz się, dlaczego Playwright to nowoczesny wybór dla testów E2E. Skonfiguruj pierwszy projekt, napisz niezawodny test używając auto-waiting i dostępnych selektorów, oraz zrozum model.

Opanuj strategię lokatorów Playwright. Dowiedz się, dlaczego selektory oparte na rolach są lepsze od CSS, kiedy używać test ID, jak filtrować i łączyć lokatory, oraz unikać kruchych wzorców, które.

Porównaj klasyczny Page Object Model z kompozycją opartą na fixture'ach Playwright. Dowiedz się, kiedy każdy wzorzec wygrywa, jak unikać obiektów-bogów i strukturyzować kod testowy dla.

Opanuj asercje web-first i auto-waiting w Playwright, aby wyeliminować niestabilne testy. Dowiedz się, dlaczego waitForTimeout to błąd, kiedy networkidle pomaga, jak działa expect.poll i czy.

Naucz się używać APIRequestContext Playwright do testowania backendu. Przygotowuj dane testowe przez API przed testami UI, waliduj odpowiedzi, obsługuj nagłówki uwierzytelniania i decyduj, kiedy.

Autentykacja w testach jest zwodniczo trudna. Dowiedz się, jak użyć storageState w Playwright, aby zalogować się raz i używać sesji wielokrotnie, testować różne role użytkowników i uniknąć.

Testy regresji wizualnej wychwytują zmiany w UI, których nie zamierzałeś. Testy dostępności wychwytują bariery, których nie zauważyłeś. Dowiedz się, kiedy testy wizualne pomagają, kiedy są szumem i.

Testy Playwright mogą działać równolegle na wielu workerach, a nawet na wielu maszynach. Dowiedz się, jak skonfigurować workery, podzielić pakiety testów dla CI, zbierać artefakty trace i wideo oraz.

Nieudane testy to nie problemy — to wskazówki. Dowiedz się, jak używać trybu UI Playwright, przeglądarki trace, debugowania headed i analizy artefaktów, aby izolować niestabilne kroki, zrozumieć.

Większość pakietów testów gnije z czasem. Testy stają się niestabilne, wolne i ignorowane. Poznaj praktyki, które utrzymują testy Playwright wartościowe wraz z rozwojem zespołu: własność, tagowanie.

Użyj routingu Playwright, żeby podstawić, przerwać albo przepuścić wywołanie. Test UI ma paść z powodu, który wybrałeś.

Chromium na każdy pull request. Firefox i WebKit tylko tam, gdzie te silniki naprawdę produkują błędy, które już widziałeś.

Testuj geolokalizację, schowek, kamerę i powiadomienia, gdy użytkownik odmawia. Fixture, który wszystko przyznaje, chowa tę ścieżkę.

Testuj pliki, które użytkownik wgrywa i pobiera: typ, rozmiar, nazwę i środek. Włączony przycisk nie dowodzi, że plik dotarł.

Gdy kliknięcie otwiera popup albo nową kartę, sprawdzaj tamtą stronę. To, że karta otwierająca została na miejscu, nie dowodzi, że nowe okno działa.

Gdy kontrolka leży w ramce iframe, wskaż ramkę przez frameLocator. Lokator na obiekcie page przeszukuje tylko główny dokument i nie widzi pola.