Чому page, browser і context називаються “фікстурами”? Це просто слово чи технічний термін?

“Fixture” — це офіційний термін у Playwright, не метафора. Слово прийшло з будівництва і спорту — це щось “зафіксоване”, підготовлене заздалегідь і готове до використання. У тестуванні fixture — це будь-який ресурс, який фреймворк готує для тебе до запуску тесту і прибирає після. Саме тому page, browser, context — це фікстури: ти їх не створюєш і не знищуєш, Playwright робить це сам.

TypeScript — з фікстурами vs без

// ✅ З фікстурами — ти просто називаєш що потрібно
test('мій тест', async ({ page, context, browser }) => {
  // page, context, browser вже готові — ти їх не створювала
  await page.goto('/shop');
});
// Після тесту Playwright сам закриває page і context. Крапка.

// ❌ Без фікстур — ти б мала писати це вручну КОЖНОГО РАЗУ:
const browser = await chromium.launch();
const context = await browser.newContext();
const page = await context.newPage();
// ... тест ...
await page.close();    // і не забути! а якщо тест впав посередині?
await context.close(); // тоді close не виконається, і браузер лишиться висіти
await browser.close();

// ─────────────────────────────────────────────────────
// Різний час життя фікстур — це теж частина "підготовки і прибирання":
//
// browser  — одна на ВЕСЬ тестовий прогін (або файл)
//            запустити Chrome — дорого (секунди)
//            тому Playwright переюзовує один процес
//
// context  — нова для КОЖНОГО тесту
//            це ізоляція: свої cookies, localStorage, cache
//            дешево створити (мілісекунди)
//
// page     — нова для КОЖНОГО тесту (живе всередині context)
//            одна вкладка = один тест

💡 Як це виглядає в документації Playwright: якщо відкрити офіційний сайт і знайти розділ “Fixtures” — там так і написано: “Built-in fixtures: page, browser, context, request”. Це не народна назва — це офіційна архітектурна концепція фреймворку, запозичена з pytest (Python), де fixtures теж є центральною ідеєю.

🔧 TypeScript / JS патерни в цьому прикладіasync ({ page }, use, testInfo) => {} — функція отримує три аргументи: інші fixtures, callback use(), і метадані тесту; testInfo.title — доступ до властивості об’єкта через крапку; Date.now() — виклик статичного методу класу; template literal `текст ${змінна}` — рядок з вбудованим виразом.

🗣 Як читати вголос“Fixture” — це офіційний термін у Playwright, не просто зручне слово. Походить від ідеї “зафіксованого, заздалегідь підготовленого ресурсу”: фреймворк сам готує його до початку тесту і сам прибирає після — незалежно від того, чи тест пройшов чи впав. Якби page не була фікстурою, тобі б довелось вручну писати chromium.launch(), browser.newContext(), context.newPage() на початку кожного тесту і відповідно page.close(), context.close(), browser.close() наприкінці. І найголовніша проблема — якщо тест впав посередині виконання, твій код прибирання просто не досягнеться, браузерні процеси залишаться висіти в пам’яті. Фікстура вирішує це елегантно: Playwright гарантує teardown fixture навіть якщо тест завершився помилкою. (Виняток: якщо процес примусово завершений — SIGKILL, OOM, killed CI runner — teardown не виконається.) Важливо, що page, context і browser мають різний час життя: браузерний процес дорого запускати, тому browser — worker-scoped: один на весь worker-процес. При паралельному запуску з 4 workers — буде 4 браузерних процеси. А context і page створюються заново для кожного тесту окремо, бо саме через них досягається ізоляція — у кожному тесті свої cookies, свій localStorage, свій чистий стан.