Jeśli zaczynasz naukę Playwrighta, to prędzej czy później trafisz na temat fixtures.
I szczerze? Na początku może to wyglądać trochę dziwnie.
Bo nagle pojawia się jakieś test.extend(), przekazywanie obiektów do testów, custom fixtures… i człowiek zaczyna się zastanawiać:
„Po co to wszystko, skoro mogę normalnie stworzyć page?”
Sam miałem podobnie.
Ale w praktyce fixtures bardzo szybko okazują się czymś, bez czego ciężko pisać większe i bardziej uporządkowane testy.
Dlatego w tym wpisie pokażę to maksymalnie prosto — bez niepotrzebnej teorii.
Czym właściwie są fixtures?
Najprościej mówiąc:
Fixtures to mechanizm, który pozwala przygotować dane, obiekty albo konfigurację przed uruchomieniem testu.
Czyli zamiast w każdym teście robić ciągle to samo:
- otwieranie strony,
- logowanie,
- tworzenie użytkownika,
- inicjalizacja page objectów,
możemy przygotować to raz i używać wszędzie.
I właśnie dlatego fixtures są tak popularne w Playwright.
Najprostszy przykład
Bez fixtures test często wygląda tak:
import { test, expect } from '@playwright/test';
test('login test', async ({ page }) => {
await page.goto('https://example.com/login');
await page.locator('#email').fill('test@test.com');
await page.locator('#password').fill('123456');
await page.locator('button').click();
await expect(page).toHaveURL(/dashboard/);
});I okej — dla jednego testu jest git.
Ale teraz wyobraź sobie:
- 50 testów,
- każdy wymaga logowania,
- każdy ma podobny setup.
No i zaczyna się kopiowanie kodu.
I tutaj wchodzą fixtures
Możemy stworzyć własną fixture:
import { test as base } from '@playwright/test';
export const test = base.extend({
loggedPage: async ({ page }, use) => {
await page.goto('https://example.com/login');
await page.locator('#email').fill('test@test.com');
await page.locator('#password').fill('123456');
await page.locator('button').click();
await use(page);
}
});A potem używać tego w testach:
test('dashboard test', async ({ loggedPage }) => {
await loggedPage.goto('/dashboard');
});I nagle:
- kod jest krótszy,
- wszystko wygląda czyściej,
- łatwiej utrzymać testy.
Dlaczego fixtures są naprawdę przydatne?
Największa zaleta?
Oddzielenie setupu od logiki testu.
Test ma testować konkretną funkcjonalność, a nie za każdym razem zajmować się logowaniem czy konfiguracją środowiska.
Dzięki temu:
- testy są bardziej czytelne,
- łatwiej znaleźć błędy,
- łatwiej rozwijać framework.
W większych projektach fixtures praktycznie stają się standardem.
Fixtures + Page Object Model
To jest moim zdaniem najlepsze połączenie.
Zamiast tworzyć page object ręcznie w każdym teście:
const loginPage = new LoginPage(page);możemy wrzucić to do fixture.
Przykład:
loginPage: async ({ page }, use) => {
await use(new LoginPage(page));
}I potem:
test('login', async ({ loginPage }) => {
await loginPage.login();
});Dużo wygodniejsze.
Czy trzeba używać fixtures?
Nie.
Do małych projektów spokojnie można bez tego żyć.
Ale jeśli:
- uczysz się Playwrighta na poważnie,
- chcesz pracować jako QA Automation Engineer,
- budujesz większy framework,
- chcesz pisać bardziej profesjonalne testy,
to zdecydowanie warto to znać.
Bo praktycznie każdy większy projekt z Playwrightem wcześniej czy później korzysta z fixtures.
Najczęstszy błąd początkujących
Bardzo często widzę jeden problem.
Ludzie wrzucają do fixtures dosłownie wszystko.
A potem:
- fixture loguje,
- tworzy dane,
- czyści bazę,
- otwiera kilka stron,
- robi pół frameworka.
I robi się chaos.
Fixtures powinny upraszczać testy, a nie ukrywać całą logikę aplikacji.
Naprawdę warto zachować umiar.
Podsumowanie
Na początku fixtures mogą wydawać się trochę „magiczne”, ale kiedy napiszesz kilka większych testów, bardzo szybko zobaczysz sens ich używania.
Ja dziś traktuję fixtures jako coś całkowicie normalnego w Playwright.
Szczególnie gdy łączysz:
- fixtures,
- Page Object Model,
- dobre locatory,
- i sensowną strukturę projektu.
Wtedy framework zaczyna wyglądać naprawdę profesjonalnie.
I co najważniejsze — dużo łatwiej się go później utrzymuje.
