Тест-дані: фабрики, фікстури, ізоляція

Що таке тестові дані і чому їх називають прихованим джерелом флаку?

Тестові дані (test data) — це все, що має існувати в системі до того, як тест почне клікати чи слати запити: користувач, товар, баланс, замовлення в потрібному статусі. Разом із ними йде поняття стану (state) — конкретна ситуація застосунку на момент перевірки. Небезпека в тому, що дані не видно в кроках сценарію: у звіті ви бачите «клік на кнопку», а не «взяли протухлий акаунт із чужого прогону». Через це тест червоніє там, де продукт справний, або, навпаки, зеленіє над реальною регресією. Саме тому стратегія даних відрізняє того, хто просто пише тести, від того, хто пише стабільні тести.

Чим фікстура відрізняється від стану і передумови?

Це три різні речі, які часто змішують. Фікстура (fixture) — фіксоване відоме оточення для тесту: заготовлений набір даних, залогінений юзер, піднятий сервіс; у сучасних ранерах цим словом називають і сам механізм, що готує оточення й прибирає його. Стан (state) — це конкретна ситуація в системі, наприклад «існує замовлення в статусі paid». Передумова (precondition) — те, що мусить бути істинним ще до першого кроку тесту. Практично межа проста: фікстура — це інструмент, стан — результат, якого вона досягає, а передумова — вимога, яку цей стан задовольняє.

Чому arrange-фазу автотесту вважають підготовкою даних?

Бо саме в arrange тест приводить систему до потрібного стану, а це і є створення та налаштування даних. Питання ніколи не стоїть як «готувати чи ні» — без передумов перевіряти нема що. Реальні питання інші: звідки взяти ці дані (файл, генератор, API, БД) і як не дати їм протекти в наступний тест. Тому дизайн arrange — це насправді дизайн стратегії тест-даних, а не просто пара рядків перед expect.

Коли статична фікстура доречніша за генерацію, а коли навпаки?

Статична фікстура — це заготовлені значення у файлі чи дампі; її сила у детермінованості й читабельності: видно рівно те, на чому тест зелений. Її слабкість — колізії та тихе старіння: захардкоджений email ламається, щойно два тести або воркери спробують створити його одночасно, а дамп із «активною підпискою» через місяць може стати «простроченим» після зміни правил бекенду. Генерація на льоту прибирає колізії й старіння, але коштує детермінованості: важче зрозуміти, на яких саме даних тест упав. Правильна відповідь — розподіл ролей, а не вибір одного. Довідкові стабільні дані (список країн, тарифи, конфіг фіч) тримають статичними, а транзакційні унікальні сутності (юзери, замовлення) генерують. Крайові значення на кшталт порожнього рядка чи 4-байтного unicode закладають явно, бо генератор їх випадково не видасть.

Що таке фабрика тест-даних і навіщо їй дефолти з можливістю перевизначення?

Фабрика (factory) — це функція-конструктор: вона віддає повністю заповнений обʼєкт з осмисленими значеннями за замовчуванням, а тобі лишає перевизначити тільки ті поля, що суттєві для конкретної перевірки. Це родич патернів Builder і Object Mother. Головна цінність не в «менше коду», а в читабельності за наміром: коли тест викликає buildUser({ role: 'admin' }), зрозуміло, що на результат впливає лише роль, а решта полів — випадковий фон. Виписуй той самий обʼєкт цілком, з усіма десятьма полями руками, — і вже не відрізниш, де значення принципове для перевірки, а де взяте абияк. Значення для полів фабрика зазвичай бере з генератора реалістичних даних.

Навіщо потрібен faker, якщо можна підставити рядок «test test»?

Faker — бібліотека для генерації правдоподібних фейкових значень: людські імена, поштові адреси, email, номери телефонів, UUID. Ця правдоподібність тут не косметика: ідеальне test test бреше про те, як виглядатимуть справжні значення, і ховає цілий клас багів. Довге прізвище з апострофом, нелатинські літери, адреса з незвичним форматом ловлять поламану верстку й помилки кодування, яких синтетично «чистий» рядок ніколи не покаже. Тобто faker не просто економить фантазію — він наближає тестові дані до бойових і робить їх ефективнішими на баг.

Чи гарантує faker унікальність значень, і чому це питання зі співбесіди?

Ні, і саме на цьому ловлять кандидатів. faker.internet.email() продукує випадкове, а не гарантовано унікальне значення: один і той самий рядок цілком може випасти вдруге, а на великій сьюті колізія настане неминуче — тут спрацьовує парадокс днів народження. Якщо покластися на «навряд чи збіжиться» для поля з унікальним ключем, рано чи пізно отримаєте 409 Conflict. Тому до таких ключів додають щось свідомо унікальне — таймстемп, номер воркера чи UUID. Faker відповідає за реалістичність, а за унікальність — окремий детермінований хвостик.

Навіщо сідувати faker і що це дає в CI?

Випадковість faker має зворотний бік — недетермінованість: кожен прогін дає інші значення, і відтворити червоний тест локально важко. Виклик faker.seed(123) фіксує стартову точку генератора, тож послідовність значень стає однаковою від прогону до прогону. Практичний прийом: у CI логувати використаний сид, і коли тест впав, повторити рівно ту саму послідовність даних на своїй машині. Це компроміс, що дає різноманіття генерації й водночас відтворюваність фікстури.

Якими чотирма способами можна довести систему до потрібного стану і як обрати між ними?

Стан на кшталт «замовлення в статусі paid» готують через UI, через API, прямим записом у БД або через бекдор. Через UI — коли обʼєкт перевірки і є сам процес створення; у решті випадків це повільно й крихко. Через API — золотий стандарт: швидко, стабільно і, головне, працює крізь ту саму бізнес-логіку, якою користується жива людина, тож неможливих станів не породжує. Пряма БД — найшвидший шлях і єдиний, коли стан недосяжний ззовні (наприклад, треба «зістарити» запис), але обходить усі інваріанти застосунку. Бекдор — спеціальний тестовий ендпоінт як компроміс між API і БД. Правило вибору одне: готуй стан на найнижчому достатньому рівні — API за замовчуванням, а БД і бекдор лише свідомо, коли інакше ніяк.

Чому підготовку стану через API вважають золотим стандартом arrange-фази?

Тому що API виграє одразу за трьома осями. Швидкість: HTTP-запит створює передумову на порядок швидше, ніж клікання по формах. Стабільність: публічний API міняється рідше, ніж верстка, тож підготовка не ламається від кожного редизайну кнопки. І найважливіше — коректність: запит проходить через ту саму валідацію й бізнес-правила, що й дія реального користувача, тому й не народжує ситуацій, яких у продакшені бути не може. Вхід так само проганяють запитом раз на весь ран і далі перевикористовують збережену сесію, а не заповнюють форму логіну перед кожним тестом.

Які ризики у прямого запису в БД і в бекдора, і коли вони все ж виправдані?

Пряма БД дає швидкість ціною коректності: INSERT обходить валідацію, тригери й обчислювані поля, тож на світ зʼявляється стан, до якого реальний код системи ніколи б не дійшов — і тест зеленіє на неможливих даних. Додатковий мінус — жорстке звʼязування зі схемою: міграція таблиці ламає підготовку. Бекдор мʼякший (це контрольований тестовий ендпоінт, а не сирий запит), але несе власну загрозу: якщо він доїде до продакшену, це готова вразливість — обхід автентифікації чи створення адмінів. Обидва інструменти тримають як виняток: коли стан справді недосяжний через API, і з ясним розумінням, що ви обходите логіку продукту.

Чому бекдор-ендпоінт не повинен існувати в продакшені?

Бекдор (backdoor) — це ендпоінт, що дозволяє одним запитом привести систему в потрібний стан в обхід звичайних перевірок, наприклад POST /test/seed-order. Саме те, що робить його зручним у тестах, робить його небезпечним у проді: ендпоінт, який створює сутності без автентифікації й валідації, — це пряма діра в безпеці, через яку сторонній може наробити адмінів чи підробити дані. Тому бекдор вмикають виключно за прапорцем середовища й пильнують, щоб у продакшен-конфігурації він був недоступний. Правило коротке: тестовий бекдор існує лише в тестових середовищах.

Чим ізоляція на тест відрізняється від ізоляції на воркер?

Ізоляція на тест означає, що arrange кожного тесту сам заводить потрібні дані й нічого не успадковує від сусіда попереду — це просто інша грань незалежності тестів. Її порушення легко впізнати: сценарій зелений у складі всієї сьюти, але червоніє, щойно запускаєш його наодинці — насправді він підхопив дані сусіда. Ізоляція на воркер зʼявляється під паралеллю: коли тести йдуть у кількох процесах, їхні дані не мають колідувати між процесами, інакше два воркери, що реєструють один email, дадуть 409 на другому. Розвʼязань два: додати до даних ознаку воркера, щоб вони не збігалися, або виділити кожному воркеру окрему пісочницю — свій акаунт, tenant чи простір імен. Перший рівень захищає від порядку й шардингу, другий — від паралельних процесів.

Тест зелений у повній сьюті, але червоний, коли запустити його окремо. Що це і в чому причина?

Це класичний симптом прихованого звʼязування через дані: тест мовчки покладається на стан, який створив хтось інший у сьюті. Наприклад, тест B робить assert на користувача, якого насправді завів тест A, тому наодинці B падає — потрібного юзера просто немає. Та сама поломка вилазить, якщо змінити порядок тестів або зашардувати сьюту між машинами. Лікування — не ретраї, а ізоляція на тест: кожен тест сам створює в arrange усе, що перевіряє, і нічого не очікує від сусідів. Якщо тест не виживає наодинці, він не незалежний, хоч би скільки разів був зеленим у наборі.

Як надійно прибирати тестові дані і чому «afterEach усе прибере» недостатньо?

Створені дані треба видаляти, бо інакше тестове сховище розбухає, простір унікальних ключів вичерпується, а майбутні прогони чіпляються за недоприбране. Стартовий інструмент — teardown у хуках (afterEach, afterAll) чи у фікстурі після use, але у нього є три дірки: тест упав посеред arrange і хук чистить за неповним списком; сам teardown кинув помилку; або воркер помер по таймауту чи OOM і хуки взагалі не виконались. Тому надійне рішення тримають на двох шарах: хук прибирає в штатному режимі, а поверх нього працює запобіжник, якому байдуже, чим скінчився тест. Роль такого запобіжника грає TTL (тестові сутності самі протухають і їх зносить фоновий джоб), нічний клінап за домовленою ознакою, одноразові акаунти чи повне скидання стану. У Playwright teardown виконується навіть після падіння тесту, що закриває першу дірку, але від смерті воркера рятує тільки зовнішня страховка.

Що таке TTL і одноразові акаунти як страховка прибирання?

TTL (time to live) — обмежений час життя тестової сутності: вона позначається так, що фоновий джоб (чи сам застосунок) видаляє її після закінчення строку, тож осиротілі дані зникають самі, навіть якщо хук не спрацював. Одноразові акаунти — інший підхід до тієї ж проблеми: замість чистити стан, тест щоразу створює свіжий акаунт і не переймається його вмістом, а прибирає їх той самий TTL-джоб. Обидва прийоми знімають залежність прибирання від успіху конкретного тесту чи виживання воркера. Ключова ідея — не намагатися видалити рівно те, що створив, а забезпечити, щоб усе тестове врешті зникло за загальною ознакою.

Як писати тести під спільний staging, який ділять кілька команд?

Спільний стенд підводить чотирма шляхами: чуже наповнення (хтось залив дві сотні замовлень — і перевірка «список має бути порожній» одразу червона), боротьба за єдиний ресурс (два прогони водночас хапають один акаунт — звідси черга й флак), ламання стану прямо під час прогону (ручний тестувальник зніс юзера, на якому тримався сценарій) і дрейф конфігурації (ввімкнули фіча-флаг — і поведінка попливла). Кодом тесту інфраструктуру не полагодити, тому рятує ізоляція на рівні даних: не спиратися на глобальний стан стенду. Замість припущення про порожній список тест сам заводить помічений власним префіксом запис і шукає рівно його серед чужих даних. Простими словами: писати тест так, ніби він на стенді не один, бо він там справді не один.

Чому не можна ганяти тести на дампі або копії продакшену?

Причин кілька, і кожної окремо достатньо. Юридична й приватна: у дампі лежать персональні дані (personally identifiable information, PII) справжніх користувачів — їхні імена, пошта, номери телефонів, подеколи платіжна інформація; щойно ця копія осідає в тестовій базі, логах чи на ноутбуці інженера, це вже обробка поза призначенням і потенційний витік, а GDPR наполягає на мінімізації даних і законній підставі, якої для такого тестування зазвичай бракує. Непередбачуваність: прод живий, і сутність, на якій тримався тест, можуть видалити чи змінити вночі платіжкою — тест стає недетермінованим за побудовою. Ризик мутації: найгірший варіант — тест не на копії, а на самому проді, і автоматизація «перевірки видалення» зносить дані реального клієнта. Потрібне «як прод», а не «прод»: синтетичні дані з faker і фабрик або анонімізований зріз, де PII замінено на фейкові зі збереженням форми й обсягу.

Що таке анонімізований зріз і чим він кращий за сирий прод-дамп?

Анонімізований (деперсоналізований) зріз — це копія структури прод-даних, у якій персональні поля замінено на фейкові з збереженням форми, розподілу й обсягу; цей процес називають маскуванням. Він дає те, заради чого взагалі тягнуться до продакшену, — реалістичний розподіл значень і крайові випадки, — але без чужих персональних даних у вашій базі, логах чи артефактах CI. На відміну від сирого дампа, тут немає юридичного ризику PII, і немає живих записів, які хтось змінить під ногами. Альтернатива тому самому — повністю синтетичні дані з фабрик і faker; вибір між ними залежить від того, наскільки важливо відтворити саме продакшн-розподіл, а не лише правдоподібну структуру.

Три кейси, де стратегія даних вирішує, зелений тест чи флак: фабрика з faker і гарантованою унікальністю, вибір рівня підготовки стану для чекауту, та ізоляція на воркер із двошаровим прибиранням. Скрізь — що робимо і чому саме так.

Кейс 1. Фабрика юзера: дефолти з faker, унікальність окремим хвостиком

Тесту потрібен адмін із балансом. Наївний варіант — тягнути повний обʼєкт із десятьма полями в кожен тест, і читач не розуміє, що з них суттєве. Фабрика прибирає цей шум: дефолти беремо з faker, а в тест виносимо тільки те, що впливає на перевірку.

import { faker } from '@faker-js/faker';

type User = { email: string; name: string; role: 'admin' | 'member'; balance: number };

// унікальний хвостик: faker дає реалістичність, а не унікальність
function uniqueEmail(): string {
  return `qa+${Date.now()}-${faker.string.alphanumeric(6)}@test.local`;
}

function buildUser(overrides: Partial<User> = {}): User {
  return {
    email: uniqueEmail(),
    name: faker.person.fullName(),
    role: 'member',
    balance: 0,
    ...overrides,
  };
}

// у тесті видно намір: суттєві лише роль і баланс
const admin = buildUser({ role: 'admin', balance: 1000 });

Що дивитися і чому:

• Унікальність не довіряємо faker. faker.internet.email() може повторитися, і на великій сьюті повториться напевно — це 409 Conflict на другому тесті. Тому email збираємо з мітки часу й випадкового суфікса, а не покладаємось на «навряд чи збіжиться».
• ...overrides іде останнім. Спред у кінці дозволяє тесту перекрити будь-який дефолт; постав його на початок — і дефолти затруть значення, які передав тест.
• Реалістичне імʼя ловить баги. faker.person.fullName() дасть прізвище з апострофом чи нелатиницею, на яких провалиться крива верстка чи кодування — те, що test test заховало б.
• Сид для відтворення. Якщо тест впав на дивному згенерованому імені, faker.seed(N) на старті ран повторить ту саму послідовність локально; сид варто логувати в CI.

Кейс 2. Той самий стан — чотири рівні. Що обрати для чекауту

Тесту чекауту потрібне замовлення в статусі paid. Спокуса зробити його кліками сильна, але дорога. Порівняння рівнів підготовки:

Для чекауту обʼєкт перевірки — оплата, а не створення замовлення, тож готуємо передумову через API:

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

test('чекаут оплаченого замовлення', async ({ page, request }) => {
  // arrange: стан готуємо запитом, не кліками — швидко й крізь ту саму бізнес-логіку
  const res = await request.post('/api/orders', {
    data: { items: [{ sku: 'BOOK-1', qty: 1 }], status: 'paid' },
  });
  expect(res.status()).toBe(201);
  const order = await res.json();

  // act + assert: перевіряємо саме те, заради чого написаний тест
  await page.goto(`/orders/${order.id}`);
  await expect(page.getByTestId('order-status')).toHaveText('Оплачено');
});

Що дивитися і чому:

• UI лишаємо для одного випадку. Готувати замовлення кліками виправдано, тільки якщо перевіряємо сам процес оформлення; інакше це повільно, крихко й змішує підготовку з перевіркою.
• API поважає інваріанти. Запит проходить крізь валідацію застосунку, тож не створить стану, неможливого в проді. Прямий INSERT того ж замовлення міг би поставити paid без запису про оплату — тест зеленів би на неможливих даних.
• Пряма БД — для недосяжного. Її беруть, коли стан ззовні не зробити, наприклад треба замовлення з датою місячної давнини для тесту на прострочення. Ціна — жорстке звʼязування зі схемою: міграція таблиці ламає підготовку.
• Бекдор лишається за прапорцем середовища. Ендпоінт POST /test/seed-order зручний, але в продакшені це діра в безпеці — його вмикають лише в тестових середовищах.

Кейс 3. Ізоляція на воркер плюс страховка на прибирання

Симптом «іноді падає в CI, локально зелено» часто означає, що два воркери деруться за той самий акаунт. Даємо кожному воркеру власний акаунт через worker-scoped фікстуру й підстраховуємо прибирання, бо хук не виживе, якщо воркер помре.

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

type Account = { id: string; email: string };

export const test = base.extend<{}, { account: Account }>({
  account: [async ({}, use, workerInfo) => {
    // власний акаунт на воркер: створюється раз, живе весь прогін воркера
    const email = `w${workerInfo.workerIndex}-${Date.now()}@test.local`;
    const account = await createAccount(email);

    await use(account);            // усі тести цього воркера працюють у ньому

    await deleteAccount(account.id); // основний прибиральник по завершенні воркера
  }, { scope: 'worker' }],
});

test('замовлення видно лише своєму акаунту', async ({ account }) => {
  const order = await createOrder(account.id, { sku: 'BOOK-1' });
  // шукаємо саме СВІЙ запис — не «список порожній» і не «рівно один»
  const list = await listOrders(account.id);
  expect(list.map((o) => o.id)).toContain(order.id);
});

Що дивитися і чому:

• Ключ воркера прибирає колізії між процесами. workerInfo.workerIndex у email гарантує, що два паралельні воркери не полізуть в один акаунт — саме та колізія, що дає плаваючі 409 у CI. Ретраї її не лікують, ізоляція лікує.
• Спільний акаунт у межах воркера — прихована пастка. Тести одного воркера знову звʼязані: якщо вони ділять один кошик, то заважають одне одному. Тому кожен створює власне замовлення в межах акаунта, а не мутує спільний стан.
• Хук — лише перший шар. deleteAccount після use прибирає в нормі, але не спрацює при OOM чи таймауті воркера. Тому email містить домовлену ознаку (@test.local), за якою нічний клінап або TTL-джоб знесе сиріт незалежно від долі тесту.
• Асерт шукає своє серед чужого. toContain(order.id) виживе на спільному стенді, де є дані інших команд; асерт «рівно 1 замовлення» червонів би від першого чужого запису.

Словник і стратегія

• Розрізняю фікстуру (fixture), стан (state) і передумову (precondition): інструмент, досягнута ситуація і вимога до неї.
• Розумію, що arrange-фаза автотесту зводиться до готування даних і стану, і питання стоїть не «чи готувати», а «звідки брати» й «як не дати протекти».

Статичні фікстури проти генерації

• Знаю сильні сторони статичної фікстури (детермінованість, читабельність) і слабкі (колізії під паралель, тихе старіння даних).
• Розумію компроміс генерації: свіжі й безколізійні дані ціною детермінованості й ризику проґавити edge-кейс.
• Знаю розподіл ролей: довідкові стабільні дані — статичні, транзакційні унікальні сутності — генеровані, крайові значення — закладені явно.

Фабрики і faker

• Можу пояснити, що фабрика (factory) — це дефолти плюс перевизначення, і її головна цінність — читабельність за наміром, а не «менше коду».
• Знаю пастку: faker.internet.email() не гарантує унікальності, тож до унікальних ключів домішую мітку часу, індекс воркера або UUID.
• Можу пояснити, навіщо сідувати faker (faker.seed()) — щоб відтворити червоний прогін за тією самою послідовністю даних.

Підготовка стану

• Знаю чотири рівні підготовки стану — UI, API, пряма БД, бекдор — і компроміси кожного.
• Тримаю в голові правило найнижчого достатнього рівня: кліки — тільки для перевірки самого UI-флоу, типовий шлях — API (швидкість, стабільність, поважання інваріантів), а БД чи бекдор беру свідомо, як виняток.
• Розумію ризик прямого INSERT: обходить валідацію й тригери, тож тест зелений на стані, який продукт ніколи не породив би.

Ізоляція

• Розрізняю ізоляцію на тест (кожен сам створює свої дані) та на воркер (дані не колідують між паралельними процесами).
• Можу пояснити симптом прихованого звʼязування: «проходить у сьюті, падає окремо» або залежить від порядку чи шардингу.
• Знаю два способи ізоляції на воркер: позначити дані ознакою воркера проти збігів або виділити кожному окрему пісочницю (акаунт, tenant).

Прибирання

• Знаю три дірки наївного teardown: падіння посеред arrange, помилка в самому teardown, смерть воркера.
• Можу пояснити двошарову стратегію: хук прибирає штатно, а зовнішній запобіжник спрацьовує незалежно від того, чим завершився тест.
• Знаю варіанти страховки: TTL, нічний клінап за ознакою, одноразові акаунти, повне скидання стану.

Спільні оточення і прод-дані

• Можу пояснити принцип «не покладайся на глобальний стан» на спільному стенді (чужі дані, гонки за ресурс, дрейф конфігурації): тест шукає власний маркований запис, а не «рівно 3 користувачі».
• Розумію три незалежні причини не брати прод-дані: PII і GDPR, непередбачуваність та старіння, ризик мутації живих записів.
• Знаю альтернативи «як прод, а не прод»: синтетичні дані з фабрик і faker або анонімізований (маскований) зріз.