Powrót do: AI_Testers vol. 1 – Bonusy (aktywnie rozwijane)

Spis treści

Lekcja 7 – Konfiguracja Playwrighta, przeglądarki i własne komendy

W tej lekcji zajmiemy się konfiguracją Playwrighta.

Do tej pory uruchamialiśmy testy głównie przez komendy wpisywane w terminalu. Teraz zobaczymy, gdzie Playwright trzyma ustawienia projektu i jak dzięki konfiguracji możemy uprościć codzienną pracę.

Omówimy plik playwright.config.ts, ustawimy baseURL, dodamy uruchamianie testów na różnych przeglądarkach, skonfigurujemy automatyczne startowanie aplikacji przez webServer oraz dodamy własne komendy w package.json.

Dzięki temu zamiast wpisywać długie komendy, będziemy mogli korzystać z prostych skryptów, takich jak npm run e2e, npm run e2e:ui czy npm run e2e:chromium.

Co zrobimy w tej lekcji?

Omówimy aktualny plik playwright.config.ts
Sprawdzimy, gdzie Playwright szuka testów
Włączymy baseURL
Uruchomimy testy na różnych przeglądarkach
Dodamy projekty dla Chromium, Firefox i WebKit
Omówimy tryb headed dla konkretnej przeglądarki
Skonfigurujemy webServer
Dodamy własne komendy w package.json
Zaktualizujemy testy po dodaniu baseURL
Wykorzystamy AI do wyjaśnienia i poprawy konfiguracji

Przydatne linki

Repozytorium aplikacji Rolnopol: https://github.com/jaktestowac/rolnopol
Playwright Configuration: https://playwright.dev/docs/test-configuration

1. `playwright.config.ts`

Plik playwright.config.ts to główne miejsce konfiguracji Playwrighta.

To tutaj ustawiamy między innymi:

gdzie znajdują się testy,
na jakich przeglądarkach mają się uruchamiać,
czy testy mają działać równolegle,
jaki raport ma zostać wygenerowany,
czy Playwright ma zbierać trace,
czy aplikacja ma zostać uruchomiona automatycznie przed testami.

Aktualnie konfiguracja zawiera między innymi:

testDir: './e2e',

To oznacza, że Playwright będzie szukał testów w katalogu e2e.

Jeśli test znajduje się w innym katalogu, np. tests, Playwright może go nie znaleźć. Dlatego należy trzymać testy E2E w katalogu wskazanym przez testDir.

2. `baseURL`

W sekcji use możemy ustawić wspólne opcje dla testów.

Jedną z najpraktyczniejszych opcji jest baseURL.

Przed zmianą:

use: {  
 // baseURL: 'http://localhost:3000',  
 trace: 'on-first-retry',  
},

Po zmianie:

use: {  
 baseURL: 'http://localhost:3000',  
 trace: 'on-first-retry',  
},

Dzięki baseURL nie musimy w każdym teście wpisywać pełnego adresu aplikacji.

Zamiast:

await page.goto('http://localhost:3000');

możemy napisać:

await page.goto('/');

Zamiast:

await page.goto('http://localhost:3000/login.html');

możemy napisać:

await page.goto('/login.html');

To sprawia, że testy są krótsze, czytelniejsze i łatwiejsze do utrzymania.

Jeśli adres aplikacji kiedyś się zmieni, wystarczy zmienić go w jednym miejscu – w konfiguracji.

3. Projekty i przeglądarki

W Playwright sekcja projects pozwala zdefiniować różne środowiska uruchamiania testów.

Aktualnie aktywny jest tylko Chromium:

projects: [
{
    name: 'chromium',
    use: { ...devices['Desktop Chrome'] },
},
],

Możemy dodać Firefox i WebKit:

projects: [
{
    name: 'chromium',
    use: { ...devices['Desktop Chrome'] },
},

{
    name: 'firefox',
    use: { ...devices['Desktop Firefox'] },
},

{
    name: 'webkit',
    use: { ...devices['Desktop Safari'] },
},
],

Dzięki temu możemy sprawdzić, czy aplikacja działa poprawnie nie tylko na Chromium, ale też na Firefoxie i WebKit.

Uruchomienie wszystkich projektów:

npx playwright test

Uruchomienie tylko Chromium:

npx playwright test --project=chromium

Uruchomienie tylko Firefox:

npx playwright test --project=firefox

Uruchomienie tylko WebKit:

npx playwright test --project=webkit

Jeśli chcesz zobaczyć test w konkretnej przeglądarce, możesz dodać --headed:

npx playwright test --project=chromium --headed

4. `webServer`

Do tej pory trzeba było pamiętać, żeby przed testami ręcznie uruchomić aplikację.

Playwright może zrobić to automatycznie dzięki opcji webServer.

Przed zmianą:

// webServer: {  
// command: 'npm run start',  
// url: 'http://localhost:3000',  
// reuseExistingServer: !process.env.CI,  
// },

Po zmianie:

webServer: {  
 command: 'npm run start',  
 url: 'http://localhost:3000',  
 reuseExistingServer: !process.env.CI,  
},

Ta konfiguracja oznacza, że Playwright:

uruchomi aplikację komendą npm run start,
poczeka, aż będzie dostępna pod adresem http://localhost:3000,
dopiero potem odpali testy,
lokalnie może użyć już działającego serwera.

To bardzo wygodne, bo zmniejsza ryzyko, że testy padną tylko dlatego, że aplikacja nie została wcześniej uruchomiona.

5. Własne komendy w `package.json`

Obecny package.json ma już komendy do uruchamiania aplikacji i testów unitowych.

Dodamy osobne komendy do testów E2E:

"e2e": "playwright test",  
"e2e:ui": "playwright test --ui",  
"e2e:headed": "playwright test --headed",  
"e2e:chromium": "playwright test --project=chromium",  
"e2e:firefox": "playwright test --project=firefox",  
"e2e:webkit": "playwright test --project=webkit",  
"e2e:report": "playwright show-report"

Po dodaniu ich do scripts możesz uruchamiać testy prostszymi komendami.

Wszystkie testy E2E:

npm run e2e

Playwright UI:

npm run e2e:ui

Tryb headed:

npm run e2e:headed

Tylko Chromium:

npm run e2e:chromium

Tylko Firefox:

npm run e2e:firefox

Tylko WebKit:

npm run e2e:webkit

Raport HTML:

npm run e2e:report

Dzięki temu nie trzeba pamiętać pełnych komend Playwrighta. Wystarczy zajrzeć do package.json.

6. Finalna konfiguracja

Po zmianach playwright.config.ts może wyglądać tak:

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
    testDir: './e2e',

    fullyParallel: true,

    forbidOnly: !!process.env.CI,

    retries: process.env.CI ? 2 : 0,

    workers: process.env.CI ? 1 : undefined,

    reporter: 'html',

    use: {
        baseURL: 'http://localhost:3000',
        trace: 'on-first-retry',
    },

projects: [
{
    name: 'chromium',
    use: { ...devices['Desktop Chrome'] },
},

{
    name: 'firefox',
    use: { ...devices['Desktop Firefox'] },
},

{
    name: 'webkit',
    use: { ...devices['Desktop Safari'] },
},

],

webServer: {
    command: 'npm run start',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
},
});

Ta konfiguracja:

szuka testów w katalogu e2e,
ustawia bazowy adres aplikacji,
uruchamia testy na Chromium, Firefox i WebKit,
generuje raport HTML,
zbiera trace przy pierwszym retry,
uruchamia aplikację przed testami.

7. AI jako wsparcie

AI może pomóc zrozumieć konfigurację i zaproponować skrypty w package.json.

Przykładowy prompt do wyjaśnienia konfiguracji:

You are an experienced QA automation engineer and Playwright mentor.

Please explain this Playwright config to a beginner.

Focus on:
– testDir
– fullyParallel
– retries
– workers
– reporter
– use.baseURL
– use.trace
– projects
– webServer

Explain what each option does and why it can be useful in a beginner-friendly Playwright project.

Prompt do dodania komend w package.json:

You are an experienced QA automation engineer.

Based on this package.json and Playwright config, suggest useful npm scripts for running Playwright E2E tests.

I want scripts for:
– running all E2E tests
– opening Playwright UI
– running tests in headed mode
– running only Chromium
– running only Firefox
– running only WebKit
– opening the HTML report

Please keep the existing scripts and add only new Playwright-related scripts.

Zadanie dla uczestnika

W playwright.config.ts odkomentuj sekcję:

/* Test against mobile viewports. */

// {

    //   name: 'Mobile Chrome',

    //   use: { ...devices['Pixel 5'] },

    // },

// {

    //   name: 'Mobile Safari',

    //   use: { ...devices['iPhone 12'] },

    // },

Sprawdź, jak testy działają na widokach mobilnych.

Co dalej?

W następnej lekcji przejdziemy do pisania kolejnych testów e2e.

Zakres kolejnej lekcji:

testy e2e dla widoku Staff & Fields Management
analiza dostępnych przypadków testowych z AI
przygotowanie testów z AI

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.