Розділ 1

Що таке фікстура

Playwright Test побудований навколо ідеї тестових фікстур. Фікстура встановлює середовище для кожного тесту: дає йому все, що потрібно, і нічого зайвого. Фікстури ізольовані між тестами, тож тести можна групувати за змістом, а не за спільним налаштуванням.

Ви вже користувалися фікстурою в першому ж тесті. Аргумент { page } — це не просто деструктуризація: він повідомляє раннеру, що тесту потрібна фікстура page, і раннер налаштує її до запуску тесту, а після завершення прибере.

import { test, expect } from '@playwright/test';

test('basic test', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  await expect(page).toHaveTitle(/Playwright/);
});

За довідником API механіка така: Playwright Test дивиться на оголошення кожного тесту, аналізує, які фікстури йому потрібні, і готує саме їх. Значення, підготовлені фікстурами, зливаються в один об'єкт, який передається першим параметром у тест, хуки, анотації та інші фікстури. Саме тому ви пишете async ({ page, request }) => ... і отримуєте рівно те, що назвали.

Розділ 2

Вбудовані фікстури

Playwright Test постачається з набором готових фікстур. Ключова відмінність між ними — область життя (scope). Браузер спільний для всіх тестів одного воркера, бо запускати його для кожного тесту дорого. Натомість контекст, сторінка й API-контекст створюються окремо для кожного тесту, тому кожен тест отримує свіже оточення, навіть коли всі вони працюють в одному браузері.

Типові сценарії з довідника API

import { test } from '@playwright/test';

// context: block requests to an external domain for this test only
test('example test', async ({ page, context }) => {
  await context.route('*external.com/*', route => route.abort());
  // ...
});

// browser: shared between tests in the same worker
test.beforeAll(async ({ browser }) => {
  const page = await browser.newPage();
  // ...
});

// browserName: annotate tests per browser
test('skip this test in Firefox', async ({ page, browserName }) => {
  test.skip(browserName === 'firefox', 'Still working on it');
  // ...
});

// request: isolated APIRequestContext per test
test('api test', async ({ request }) => {
  await request.post('/signin', {
    data: {
      username: 'user',
      password: 'password',
    },
  });
  // ...
});

Вбудовані option-фікстури з TestOptions

Окрім «робочих» фікстур, Playwright Test надає опції, через які налаштовуються browser, context і page. Це теж фікстури, тільки їхнє значення ви задаєте декларативно: у блоці use конфігу, у конкретному проєкті або локально у файлі через test.use(). Серед них baseURL, storageState, viewport, locale, colorScheme, trace, screenshot, video; у версії 1.63 до них додалися окремі опції reducedMotion, forcedColors і contrast.

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

export default defineConfig({
  use: {
    baseURL: 'https://playwright.dev',
    storageState: 'state.json',
  },
});

import { test } from '@playwright/test';

// Override an option fixture for this file only.
test.use({ baseURL: 'https://playwright.dev/docs/intro' });

Оскільки це фікстури, від них можуть залежати ваші власні фікстури — наприклад, перевизначена page у розділі 6 бере baseURL зі своїх аргументів.

fixtures.mount NEW in 1.62

У версії 1.62 компонентне тестування перейшло на модель stories і galleries, і з'явилася фікстура mount. Story — це маленький компонент-обгортка, який вбудовує тестований компонент в один конкретний сценарій: захардкоджені props, мок-дані, провайдери, записані колбеки. Gallery — сторінка, яку ви реалізуєте самі й віддаєте за адресою baseURL; вона надає функції window.mount(params) і window.unmount(), що рендерять story в кореневий елемент.

Кожен виклик mount() переходить на baseURL і викликає window.mount() з ідентифікатором story та props, тож тести повністю ізольовані один від одного. Повертається Locator, що вказує на кореневий елемент, у який відрендерилась story, — і запити варто будувати саме від нього: component.getByRole('button'), а не page.getByRole('button').

import { test, expect } from '@playwright/test';

test('click should expand', async ({ mount }) => {
  const component = await mount('components/Expandable/Stateful');
  await component.getByRole('button').click();
  await expect(component.getByTestId('expanded')).toHaveValue('true');
});

Щоб перевіряти типи props, передайте тип story як generic-аргумент:

import { test, expect } from '@playwright/test';
import type { WithTitle } from './Button.story';

test('renders the title', async ({ mount }) => {
  const component = await mount<typeof WithTitle>('Button/WithTitle', { title: 'Hello' });
  await expect(component).toContainText('Hello');
});

Повернутий локатор доповнений двома методами: update(props) перерендерює ту саму story з новими props без перемонтування, зберігаючи стан компонента, а unmount() демонтує story. Аргумент storyId — ідентифікатор, який розпізнає gallery; за конвенцією це шлях до файлу story плюс ім'я експорту, наприклад 'components/Button/Primary'. Props необов'язкові й мають бути простими серіалізованими значеннями. У нотатках до 1.63 додано, що ідентифікатори stories можна типізувати через згенерований реєстр Stories, а старі пакети @playwright/experimental-ct-* для React і Vue більше не оновлюватимуться.

Розділ 3

Без фікстур vs з фікстурами

Документація порівнює два стилі на прикладі TodoPage — класу за патерном Page Object Model, який працює з todo-списком через внутрішній page. У традиційному стилі екземпляр живе у змінній describe-блоку, створюється в beforeEach і прибирається в afterEach. У стилі з фікстурами той самий життєвий цикл описаний в одному місці.

import type { Page, Locator } from '@playwright/test';

export class TodoPage {
  private readonly inputBox: Locator;
  private readonly todoItems: Locator;

  constructor(public readonly page: Page) {
    this.inputBox = this.page.locator('input.new-todo');
    this.todoItems = this.page.getByTestId('todo-item');
  }

  async goto() {
    await this.page.goto('https://demo.playwright.dev/todomvc/');
  }

  async addToDo(text: string) {
    await this.inputBox.fill(text);
    await this.inputBox.press('Enter');
  }

  async remove(text: string) {
    const todo = this.todoItems.filter({ hasText: text });
    await todo.hover();
    await todo.getByLabel('Delete').click();
  }

  async removeAll() {
    while ((await this.todoItems.count()) > 0) {
      await this.todoItems.first().hover();
      await this.todoItems.getByLabel('Delete').first().click();
    }
  }
}

import { test } from '@playwright/test';
import { TodoPage } from './todo-page';

test.describe('todo tests', () => {
  let todoPage: TodoPage;

  test.beforeEach(async ({ page }) => {
    todoPage = new TodoPage(page);
    await todoPage.goto();
    await todoPage.addToDo('item1');
    await todoPage.addToDo('item2');
  });

  test.afterEach(async () => {
    await todoPage.removeAll();
  });

  test('should add an item', async () => {
    await todoPage.addToDo('my item');
    // ...
  });

  test('should remove an item', async () => {
    await todoPage.remove('item1');
    // ...
  });
});

import { test as base } from '@playwright/test';
import { TodoPage } from './todo-page';

// Extend basic test by providing a "todoPage" fixture.
const test = base.extend<{ todoPage: TodoPage }>({
  todoPage: async ({ page }, use) => {
    const todoPage = new TodoPage(page);
    await todoPage.goto();
    await todoPage.addToDo('item1');
    await todoPage.addToDo('item2');
    await use(todoPage);
    await todoPage.removeAll();
  },
});

test('should add an item', async ({ todoPage }) => {
  await todoPage.addToDo('my item');
  // ...
});

test('should remove an item', async ({ todoPage }) => {
  await todoPage.remove('item1');
  // ...
});

Переваги фікстур за документацією

Розділ 4

Створення кастомної фікстури

Власна фікстура створюється через test.extend(): метод повертає новий об'єкт test, який уміє все те саме, що й базовий, плюс ваші фікстури. У TypeScript типи фікстур описують окремим типом і передають першим generic-параметром — base.extend<MyFixtures>().

Кожна фікстура — це асинхронна функція виду async ({ залежності }, use, testInfo) => { ... }. Першим аргументом вона деструктуризує інші фікстури, від яких залежить (тут page). Другим отримує функцію use. Третім — testInfo з метаданими поточного тесту; у воркер-фікстур на цьому місці workerInfo. Усе, що написано до await use(value), — фаза setup; значення, передане в use, отримує тест; усе після — фаза teardown, яка виконується, коли фікстура тесту більше не потрібна.

import type { Page } from '@playwright/test';

export class SettingsPage {
  constructor(public readonly page: Page) {
  }

  async switchToDarkMode() {
    // ...
  }
}

import { test as base } from '@playwright/test';
import { TodoPage } from './todo-page';
import { SettingsPage } from './settings-page';

// Declare the types of your fixtures.
type MyFixtures = {
  todoPage: TodoPage;
  settingsPage: SettingsPage;
};

// Extend base test by providing "todoPage" and "settingsPage".
// This new "test" can be used in multiple test files, and each of them will get the fixtures.
export const test = base.extend<MyFixtures>({
  todoPage: async ({ page }, use) => {
    // Set up the fixture.
    const todoPage = new TodoPage(page);
    await todoPage.goto();
    await todoPage.addToDo('item1');
    await todoPage.addToDo('item2');

    // Use the fixture value in the test.
    await use(todoPage);

    // Clean up the fixture.
    await todoPage.removeAll();
  },

  settingsPage: async ({ page }, use) => {
    await use(new SettingsPage(page));
  },
});
export { expect } from '@playwright/test';

Зверніть увагу на останній рядок: файл фікстур реекспортує expect, щоб тести імпортували і test, і expect з одного місця — з ./my-test, а не з @playwright/test.

Розділ 5

Використання фікстур у тестах, хуках та інших фікстурах

Щоб скористатися фікстурою, достатньо згадати її в аргументах тестової функції — про решту подбає раннер. Фікстури доступні так само в хуках і в інших фікстурах: todoPage вище вже залежить від page. Якщо ви пишете на TypeScript, фікстури типобезпечні: редактор підкаже доступні імена й типи значень, а опечатка в назві стане помилкою компіляції.

import { test, expect } from './my-test';

test.beforeEach(async ({ settingsPage }) => {
  await settingsPage.switchToDarkMode();
});

test('basic test', async ({ todoPage, page }) => {
  await todoPage.addToDo('something nice');
  await expect(page.getByTestId('todo-title')).toContainText(['something nice']);
});

Тут хук beforeEach отримує settingsPage, а тест — і кастомну todoPage, і вбудовану page. Обидві сторінки-обгортки працюють з тим самим екземпляром page в межах тесту, бо тест-фікстура створюється один раз на тест.

Розділ 6

Перевизначення (override) вбудованих фікстур

Окрім створення нових фікстур, можна перевизначати наявні. Класичний приклад з документації — page, яка автоматично переходить на baseURL. Перевизначена фікстура може залежати від самої себе в базовому варіанті (page в аргументах — це вбудована сторінка) та від інших вбудованих фікстур, як-от option-фікстури baseURL.

import { test as base } from '@playwright/test';

export const test = base.extend({
  page: async ({ baseURL, page }, use) => {
    // baseURL is typed as string | undefined
    if (baseURL)
      await page.goto(baseURL);
    await use(page);
  },
});

Тепер baseURL налаштовується в конфігу або локально у файлі:

test.use({ baseURL: 'https://playwright.dev' });

Фікстуру можна й повністю замінити на щось інше. Документація показує перевизначення option-фікстури storageState, щоб подати власні дані замість значення з конфігу:

import { test as base } from '@playwright/test';
import { getAuthCookie } from './auth-helpers'; // your own helper

export const test = base.extend({
  storageState: async ({}, use) => {
    const cookie = await getAuthCookie();
    await use({ cookies: [cookie], origins: [] });
  },
});

У документації передається лише { cookies: [cookie] }; поле origins: [] додано, щоб об'єкт відповідав типу storage state у TypeScript.

Розділ 7

Worker-scoped фікстури

Playwright Test запускає тестові файли у воркер-процесах. Як тест-фікстури налаштовуються для кожного запуску тесту, так воркер-фікстури налаштовуються для кожного воркер-процесу. Це місце для сервісів, серверів і всього, що дорого створювати. Раннер перевикористовує воркер для стількох тестових файлів, скільки зможе, — за умови, що воркер-фікстури збігаються, тобто оточення ідентичні.

Воркер-фікстура оголошується кортежем: функція плюс об'єкт опцій { scope: 'worker' }. Без цієї опції раннер вважатиме її звичайною тест-фікстурою. Типи воркер-фікстур передаються другим generic-параметром — base.extend<{}, { account: Account }>. Для унікальних даних документація використовує workerInfo.workerIndex, доступний у будь-якому тесті чи фікстурі.

import { test as base, expect } from '@playwright/test';

type Account = {
  username: string;
  password: string;
};

// Note that we pass worker fixture types as a second template parameter.
export const test = base.extend<{}, { account: Account }>({
  account: [async ({ browser }, use, workerInfo) => {
    // Unique username.
    const username = 'user' + workerInfo.workerIndex;
    const password = 'verysecure';

    // Create the account with Playwright.
    const page = await browser.newPage();
    await page.goto('/signup');
    await page.getByLabel('User Name').fill(username);
    await page.getByLabel('Password').fill(password);
    await page.getByText('Sign up').click();
    // Make sure everything is ok.
    await expect(page.getByTestId('result')).toHaveText('Success');
    // Do not forget to cleanup.
    await page.close();

    // Use the account value.
    await use({ username, password });
  }, { scope: 'worker' }],

  page: async ({ page, account }, use) => {
    // Sign in with our account.
    const { username, password } = account;
    await page.goto('/signin');
    await page.getByLabel('User Name').fill(username);
    await page.getByLabel('Password').fill(password);
    await page.getByText('Sign in').click();
    await expect(page.getByTestId('userinfo')).toHaveText(username);

    // Use signed-in page in the test.
    await use(page);
  },
});
export { expect };

Акаунт створюється один раз на воркер, а перевизначена page логіниться в нього перед кожним тестом. Окрім того, що воркер-фікстури запускаються раз на воркер, вони отримують власний таймаут, рівний таймауту тесту за замовчуванням; змінити його можна опцією timeout (розділ 9).

Розділ 8

Automatic фікстури

Автоматичні фікстури налаштовуються для кожного тесту чи воркера, навіть якщо тест не згадує їх у своїх аргументах. Для цього використовується кортежний синтаксис з опцією { auto: true }. Оскільки тест не отримує від такої фікстури значення, її тип зазвичай void, а виклик — await use() без аргументу.

Приклад з документації автоматично прикріплює налагоджувальні логи, коли тест падає. Фікстура використовує testInfo: після await use() порівнює testInfo.status з testInfo.expectedStatus, отримує унікальний шлях до файлу через testInfo.outputPath() і додає вкладення в testInfo.attachments, щоб його було видно в репорті.

import debug from 'debug';
import fs from 'fs';
import { test as base } from '@playwright/test';

export const test = base.extend<{ saveLogs: void }>({
  saveLogs: [async ({}, use, testInfo) => {
    // Collecting logs during the test.
    const logs: string[] = [];
    debug.log = (...args) => logs.push(args.map(String).join(''));
    debug.enable('myserver');

    await use();

    // After the test we can check whether the test passed or failed.
    if (testInfo.status !== testInfo.expectedStatus) {
      // outputPath() API guarantees a unique file name.
      const logFile = testInfo.outputPath('logs.txt');
      await fs.promises.writeFile(logFile, logs.join('\n'), 'utf8');
      testInfo.attachments.push({ name: 'logs', contentType: 'text/plain', path: logFile });
    }
  }, { auto: true }],
});
export { expect } from '@playwright/test';

Приклад використовує npm-пакет debug; для TypeScript також знадобляться його типи.

Розділ 9

Таймаут фікстури

Фікстура вважається частиною тесту, тому час її setup і teardown зараховується в таймаут тесту. Повільна фікстура може спричинити таймаут самого тесту. Щоб не піднімати загальний таймаут, фікстурі можна дати окремий, більший таймаут через опцію timeout у кортежі.

import { test as base, expect } from '@playwright/test';

const test = base.extend<{ slowFixture: string }>({
  slowFixture: [async ({}, use) => {
    // ... perform a slow operation ...
    await use('hello');
  }, { timeout: 60000 }],
});

test('example test', async ({ slowFixture }) => {
  // ...
});

На відміну від звичайних тест-фікстур, кожна воркер-фікстура має власний таймаут, рівний таймауту тесту, і його змінюють так само — опцією timeout.

Розділ 10

Option-фікстури

Playwright Test вміє запускати кілька проєктів з окремими налаштуваннями. Option-фікстури роблять такі налаштування декларативними й типобезпечними. Опція оголошується кортежем [значенняЗаЗамовчуванням, { option: true }], а інші фікстури можуть від неї залежати, як від будь-якої іншої.

import { test as base } from '@playwright/test';
import { TodoPage } from './todo-page';

// Declare your options to type-check your configuration.
export type MyOptions = {
  defaultItem: string;
};
type MyFixtures = {
  todoPage: TodoPage;
};

// Specify both option and fixture types.
export const test = base.extend<MyOptions & MyFixtures>({
  // Define an option and provide a default value.
  // We can later override it in the config.
  defaultItem: ['Something nice', { option: true }],

  // Our "todoPage" fixture depends on the option.
  todoPage: async ({ page, defaultItem }, use) => {
    const todoPage = new TodoPage(page);
    await todoPage.goto();
    await todoPage.addToDo(defaultItem);
    await use(todoPage);
    await todoPage.removeAll();
  },
});
export { expect } from '@playwright/test';

У конфігу тип опцій передається в defineConfig<MyOptions>, і тоді значення в use перевіряються компілятором. Різні проєкти отримують різні значення:

import { defineConfig } from '@playwright/test';
import type { MyOptions } from './my-test';

export default defineConfig<MyOptions>({
  projects: [
    {
      name: 'shopping',
      use: { defaultItem: 'Buy milk' },
    },
    {
      name: 'wellbeing',
      use: { defaultItem: 'Exercise!' },
    },
  ],
});

Гайд Parameterize tests показує той самий підхід з опцією person: проєкт alice запускає тести зі значенням 'Alice', а bob — з 'Bob'. У нотатках до версії 1.60 зазначено, що раннер видає помилку, якщо конфіг намагається перевизначити фікстуру, яка не є опцією, — тож через use у конфігу задаються саме option-фікстури.

Масив як значення опції

Якщо значення опції — масив, його треба обгорнути ще в один масив і передати scope. Причина в тому, що масив у позиції значення раннер сприймає як кортеж «значення + опції».

import { test as base } from '@playwright/test';

type Person = { name: string };
const test = base.extend<{ persons: Person[] }>({
  // Declare the option, default value is an empty array.
  persons: [[], { option: true }],
});

// Option value is an array of persons.
const actualPersons = [{ name: 'Alice' }, { name: 'Bob' }];
test.use({
  // CORRECT: Wrap the value into an array and pass the scope.
  persons: [actualPersons, { scope: 'test' }],
});

test.use({
  // WRONG: passing an array value directly will not work.
  persons: actualPersons,
});

Скидання опції

Щоб повернути опцію до значення з конфігу, присвойте їй undefined. Наприклад, конфіг задає baseURL: 'https://playwright.dev', файл перевизначає його, а окремий блок повертає конфігове значення:

import { test } from '@playwright/test';

// Configure baseURL for this file.
test.use({ baseURL: 'https://playwright.dev/docs/intro' });

test('check intro contents', async ({ page }) => {
  // This test will use "https://playwright.dev/docs/intro" base url as defined above.
});

test.describe(() => {
  // Reset the value to a config-defined one.
  test.use({ baseURL: undefined });

  test('can navigate to intro from the home page', async ({ page }) => {
    // This test will use "https://playwright.dev" base url as defined in the config.
  });
});

Якщо ж потрібно повністю зробити значення undefined, а не конфіговим, використовують довгу форму фікстури:

import { test } from '@playwright/test';

// Completely unset baseURL for this file.
test.use({
  baseURL: [async ({}, use) => {
    await use(undefined);
  }, { scope: 'test' }],
});

test('no base url', async ({ page }) => {
  // This test will not have a base url.
});

Розділ 11

Порядок виконання

Кожна фікстура має фазу setup до виклику await use() і фазу teardown після нього. Setup виконується перед тестом або хуком, якому фікстура потрібна, а teardown — коли тест чи хук її більше не використовує. Порядок визначають три правила:

import { test as base } from '@playwright/test';

const test = base.extend<{
  testFixture: string,
  autoTestFixture: string,
  unusedFixture: string,
}, {
  workerFixture: string,
  autoWorkerFixture: string,
}>({
  workerFixture: [async ({ browser }, use) => {
    // workerFixture setup...
    await use('workerFixture');
    // workerFixture teardown...
  }, { scope: 'worker' }],

  autoWorkerFixture: [async ({ browser }, use) => {
    // autoWorkerFixture setup...
    await use('autoWorkerFixture');
    // autoWorkerFixture teardown...
  }, { scope: 'worker', auto: true }],

  testFixture: [async ({ page, workerFixture }, use) => {
    // testFixture setup...
    await use('testFixture');
    // testFixture teardown...
  }, { scope: 'test' }],

  autoTestFixture: [async ({}, use) => {
    // autoTestFixture setup...
    await use('autoTestFixture');
    // autoTestFixture teardown...
  }, { scope: 'test', auto: true }],

  unusedFixture: [async ({ page }, use) => {
    // unusedFixture setup...
    await use('unusedFixture');
    // unusedFixture teardown...
  }, { scope: 'test' }],
});

test.beforeAll(async () => { /* ... */ });
test.beforeEach(async ({ page }) => { /* ... */ });
test('first test', async ({ page }) => { /* ... */ });
test('second test', async ({ testFixture }) => { /* ... */ });
test.afterEach(async () => { /* ... */ });
test.afterAll(async () => { /* ... */ });

Коли всі тести проходять без помилок, документація описує такий порядок. На старті воркера налаштовується browser, бо він потрібен autoWorkerFixture, потім сама autoWorkerFixture (автоматичні воркер-фікстури налаштовуються раніше за все) і лише тоді виконується beforeAll. Для першого тесту спочатку налаштовується autoTestFixture — автоматичні тест-фікстури завжди стартують до тесту й beforeEach, потім page, бо її вимагає beforeEach; далі йдуть beforeEach, тест і afterEach, після чого знищуються page і autoTestFixture. Другий тест повторює початок, але після beforeEach лениво налаштовується workerFixture (її потребує testFixture) і сама testFixture; після тесту й afterEach знищуються testFixture, page і autoTestFixture. Наприкінці виконується afterAll, а потім знищуються workerFixture, autoWorkerFixture і browser.

Кілька спостережень з документації: page і autoTestFixture створюються й знищуються для кожного тесту; unusedFixture не налаштовується ніколи, бо її не використовує жоден тест чи хук; testFixture залежить від workerFixture і запускає її setup; workerFixture налаштовується ліниво перед другим тестом, але знищується один раз під час завершення воркера; autoWorkerFixture налаштовується для хука beforeAll, а autoTestFixture — ні.

Розділ 12

mergeTests: об'єднання фікстур з кількох модулів

Коли фікстури розкладені по різних файлах чи модулях, mergeTests() об'єднує кілька об'єктів test в один. Тест, що імпортує результат, бачить фікстури з усіх джерел одразу, разом із вбудованими.

import { mergeTests } from '@playwright/test';
import { test as dbTest } from './db-fixtures';
import { test as a11yTest } from './a11y-fixtures';

export const test = mergeTests(dbTest, a11yTest);

import { test } from './fixtures';

test('passes', async ({ database, page, a11y }) => {
  // use database and a11y fixtures.
});

У документації модулі називаються database-test-utils і a11y-test-utils; тут замінено на локальні файли, суть та сама. Для кастомних матчерів з кількох модулів існує парний mergeExpects().

Розділ 13

Box-фікстури і кастомний title

Зазвичай кастомні фікстури показуються окремими кроками в UI mode, Trace Viewer і різних репортах, а також з'являються в повідомленнях про помилки раннера. Для часто вживаних фікстур це може давати багато шуму. «Запакована» фікстура — з опцією { box: true } — ховає свої кроки з інтерфейсу. Це зручно для нецікавих допоміжних фікстур, наприклад автоматичної, яка готує спільні дані.

import { test as base } from '@playwright/test';

export const test = base.extend<{ helperFixture: void }>({
  helperFixture: [async ({}, use) => {
    // ...
    await use();
  }, { box: true }],
});

Значення box: 'self' ховає лише саму фікстуру, але залишає в репорті всі кроки, що виконуються всередині неї.

Кастомний title

Замість звичайного імені фікстурі можна дати власну назву, яка показуватиметься в тестових репортах і повідомленнях про помилки.

import { test as base } from '@playwright/test';

export const test = base.extend<{ innerFixture: void }>({
  innerFixture: [async ({}, use) => {
    // ...
    await use();
  }, { title: 'my fixture' }],
});

Розділ 14

Глобальні хуки через auto-фікстури

Хуки test.beforeEach() і test.afterEach() працюють лише для тестів у тому самому файлі й тому самому describe-блоці. Щоб отримати глобальний аналог, оголошують автоматичну тест-фікстуру. Код до await use() виконується перед кожним тестом, код після — після кожного.

import { test as base } from '@playwright/test';

export const test = base.extend<{ forEachTest: void }>({
  forEachTest: [async ({ page }, use) => {
    // This code runs before every test.
    await page.goto('http://localhost:8000');
    await use();
    // This code runs after every test.
    console.log('Last URL:', page.url());
  }, { auto: true }],  // automatically starts for every test.
});

import { test } from './fixtures';
import { expect } from '@playwright/test';

test('basic', async ({ page }) => {
  await expect(page).toHaveURL('http://localhost:8000');
  await page.goto('https://playwright.dev');
});

Глобальні beforeAll/afterAll

test.beforeAll() і test.afterAll() виконуються раз на воркер-процес, але знову ж лише для тестів свого файлу й describe. Глобальний аналог — автоматична воркер-фікстура з { scope: 'worker', auto: true }. Вона так само запускається раз на воркер-процес, просто її не треба оголошувати в кожному файлі.

import { test as base } from '@playwright/test';

export const test = base.extend<{}, { forEachWorker: void }>({
  forEachWorker: [async ({}, use, workerInfo) => {
    // This code runs before all the tests in the worker process.
    console.log(`Starting test worker ${workerInfo.workerIndex}`);
    await use();
    // This code runs after all the tests in the worker process.
    console.log(`Stopping test worker ${workerInfo.workerIndex}`);
  }, { scope: 'worker', auto: true }],  // automatically starts for every worker.
});

Документація отримує індекс через test.info().workerIndex; тут використано третій аргумент workerInfo, який воркер-фікстура отримує напряму, — так TypeScript не скаржиться на звернення до test всередині власного оголошення.

Розділ 15

Шпаргалка опцій кортежу

Усі опції передаються другим елементом кортежу: name: [fn, { ...опції }] або, для option-фікстур, name: [значення, { option: true }].

Практика

Знайди помилку

У кожному фрагменті є помилка, яка прямо випливає з документації. Спробуйте знайти її самостійно, а потім відкрийте пояснення.

Перевірка

Фінальний квіз

Десять питань за матеріалом уроку. Відповідь фіксується одразу після вибору.