Jedna z pierwszych rzeczy, które zaczynają irytować przy większych projektach w Playwright, to ciągłe logowanie użytkownika przed każdym testem.
Na początku zwykle wygląda to tak:
- otwieramy stronę,
- wpisujemy login,
- wpisujemy hasło,
- klikamy „Login”,
- czekamy,
- dopiero wtedy zaczynamy właściwy test.
Przy kilku testach jeszcze da się z tym żyć. Problem zaczyna się wtedy, gdy:
- mamy kilkadziesiąt albo kilkaset testów,
- testy uruchamiają się równolegle,
- logowanie trwa kilka sekund,
- środowisko zaczyna być niestabilne,
- testy robią się flaky.
W praktyce bardzo szybko okazuje się, że większość czasu nie tracimy na testowanie aplikacji, tylko na… samo logowanie.
I właśnie tutaj wchodzi authentication state.
Czym właściwie jest authentication state?
Playwright pozwala zapisać aktualny stan sesji użytkownika do pliku.
Mówiąc prościej:
- logujemy się raz,
- Playwright zapisuje cookies i local storage,
- później kolejne testy korzystają już z gotowej sesji.
Dzięki temu:
- testy są szybsze,
- stabilniejsze,
- prostsze,
- nie trzeba powielać logowania w każdym teście.
To jedna z tych rzeczy, które na początku wydają się „opcjonalne”, ale przy większym frameworku praktycznie stają się obowiązkowe.
Najprostsze podejście — zapisanie sesji do pliku
Najczęściej robię to w osobnym pliku, np. auth.setup.ts.
import { test as setup, expect } from '@playwright/test';
setup('authenticate', async ({ page }) => {
await page.goto('https://example.com/login');
await page.getByLabel('Email').fill('test@test.com');
await page.getByLabel('Password').fill('password123');
await page.getByRole('button', { name: 'Login' }).click();
await expect(page).toHaveURL('https://example.com/dashboard');
await page.context().storageState({
path: 'playwright/.auth/user.json'
});
});Po wykonaniu tego setupu Playwright zapisze:
- cookies,
- localStorage,
- session data.
Do zwykłego pliku JSON.
Jak używać zapisanej sesji?
Później wystarczy dodać storageState w konfiguracji.
use: {
storageState: 'playwright/.auth/user.json'
}I gotowe.
Każdy test startuje już jako zalogowany użytkownik.
Bez:
- wpisywania loginu,
- wpisywania hasła,
- klikania formularzy,
- czekania na redirecty.
Przy większych projektach różnica w czasie wykonywania testów potrafi być naprawdę ogromna.
Dlaczego to jest dużo lepsze niż logowanie w beforeEach?
Wiele osób robi coś takiego:
test.beforeEach(async ({ page }) => {
await login(page);
});Technicznie działa.
Ale przy większej liczbie testów:
- robi się wolno,
- backend dostaje setki logowań,
- testy zaczynają się wywalać,
- auth bywa rate limitowany,
- pojawiają się problemy z timeoutami.
Authentication state eliminuje większość tych problemów.
Uwaga na wygasające sesje
I tutaj pojawia się rzecz, o której początkujący często zapominają.
Jeśli token albo sesja wygasa:
- zapisany
storageStateprzestaje działać, - testy nagle zaczynają być niezalogowane.
Dlatego dobrym podejściem jest:
- generowanie nowego auth state przed uruchomieniem testów,
- albo odświeżanie sesji automatycznie.
Osobne sesje dla różnych użytkowników
W realnych projektach często mamy więcej niż jednego użytkownika.
Np:
- admin,
- manager,
- zwykły user,
- read-only user.
I wtedy można przygotować kilka auth state.
playwright/.auth/admin.json
playwright/.auth/user.json
playwright/.auth/manager.jsonA później używać ich zależnie od testu.
test.use({
storageState: 'playwright/.auth/admin.json'
});To bardzo wygodne przy testowaniu uprawnień i ról.
Authentication state a testy równoległe
To też ważny temat.
Playwright działa bardzo dobrze równolegle, ale trzeba uważać, żeby:
- testy nie nadpisywały sobie danych,
- użytkownicy nie korzystali z tych samych rekordów,
- backend nie blokował sesji.
Przy większych projektach często kończy się na:
- osobnych użytkownikach testowych,
- dynamicznych danych,
- izolacji testów.
I to jest moment, w którym automatyzacja zaczyna przypominać normalny software engineering, a nie tylko „klikanie po UI”.
Czy authentication state ma jakieś wady?
Tak.
Nie zawsze warto go używać.
Np:
- jeśli testujesz sam proces logowania,
- MFA,
- reset hasła,
- SSO,
- OAuth flow,
- timeout sesji.
W takich przypadkach lepiej wykonać pełny login.
Authentication state najlepiej sprawdza się wtedy, gdy:
- logowanie nie jest celem testu,
- chcesz szybko przejść do właściwej funkcjonalności.
Podsumowanie
Authentication state to jedna z tych funkcji Playwrighta, która bardzo szybko zmienia sposób budowania frameworka testowego.
Na początku wydaje się małym usprawnieniem.
Ale kiedy liczba testów rośnie, nagle okazuje się, że:
- testy wykonują się dużo szybciej,
- framework jest stabilniejszy,
- backend dostaje mniej requestów,
- kod robi się prostszy,
- a flaky tests pojawiają się dużo rzadziej.
I szczerze mówiąc — dzisiaj trudno mi sobie wyobrazić większy projekt Playwright bez dobrze ogarniętego authentication state.
