Тестові дані і БД в автотестах

Чим відрізняються сід, фікстура і фабрика?

Це три різні речі, які часто плутають. Сід (seed) — спільний довгоживучий фундамент середовища: довідники, каталог, кілька еталонних акаунтів, залиті один раз для всіх. Фікстура (fixture) — стан, приготований під конкретний тест чи групу («є замовлення в статусі pending»); у Playwright це слово означає ще й механізм фреймворку, що видає тесту готовий об'єкт, а після тесту сам робить прибирання. Фабрика (factory) — функція-конструктор із розумними дефолтами й точковими перевизначеннями, createUser({ role: 'admin' }); у парі з faker вона щоразу видає свіжу унікальну сутність. Найкраще масштабуються саме фабрики: сід дає каркас, а все потрібне під власну перевірку тест створює собі фабрикою й не залежить від чужих рядків.

Ти готуєш тестові дані через API чи прямо в базі? Що обереш і чому?

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

Що таке «неможливий стан» і як прямий INSERT його породжує?

Неможливий стан — це рядки в базі, яких сам застосунок ніколи б не створив: замовлення без позицій, підписка без користувача, агрегат, що не сходиться. Прямий INSERT швидкий і всесильний саме тому, що йде в обхід бізнес-логіки — а разом із нею і в обхід усіх гарантій: пропустив залежний рядок, лічильник чи зовнішній ключ (foreign key), і база містить те, чого на проді не існує. Наслідки два, і обидва погані: тест падає без реальної причини або, гірше, проходить на фікції. Це не баг продукту — це кривий сід; коли застосунок «падає» на таких даних, він поводиться правильно, бо йому підсунули те, що його інваріанти забороняють. Тому такий стан треба готувати через API, який ці інваріанти поважає.

Які є підходи до ізоляції тестів і де межа кожного?

Класичних три, і в кожного своя ціна. Унікальні дані (неймспейсинг) — щоразу створювати рядки з унікальним ключем (email із таймстемпом, логін із UUID); тести не перетинаються, бо працюють з різними рядками, і це єдиний підхід, що безпечно живе на спільній базі й під паралеллю, але база засмічується. Відкат транзакції (rollback) — обгорнути тест у BEGIN і зробити ROLLBACK наприкінці; швидко й чисто, але лише коли код застосунку й тест ділять одне з'єднання. Прибирання через TRUNCATE — скинути таблиці до відомого стану між тестами; швидко, але операція руйнівна й припустима тільки на виділеній базі, а на MySQL ще й невідкатна (там TRUNCATE дає неявний commit, тоді як у PostgreSQL він відкочується разом із транзакцією). Сильна відповідь на співбесіді називає не лише механізми, а й межі: чому rollback не працює в e2e і чому TRUNCATE не можна на спільному стейджі.

Чому «унікальні дані на воркер» — єдиний підхід, що безпечний на спільній базі й під паралеллю?

Бо він нічого не руйнує й ні за що не конкурує. Замість прибирати за собою кожен тест створює дані з унікальним ключем, тож два тести фізично працюють із різними рядками й не бачать чужих змін — навіть якщо база спільна, а воркерів багато. Інші два підходи це не витримують: варто одному воркеру зачистити таблиці посеред прогону — і другий втрачає рядки, у яких саме працює; спільний акаунт серіалізує тести навколо свого стану. Розплата за унікальні дані одна — база поступово заростає сміттям, тож поруч має жити окреме прибирання (за TTL чи нічним джобом), а не teardown усередині тесту. Тому для спільних середовищ це дефолт: номер воркера в email, префіксі чи назві проєкту робить кожен воркер власним неймспейсом.

Чому відкат транзакції не працює в класичному e2e з Playwright?

Бо відкат вимагає, щоб код застосунку й тест ділили одне й те саме з'єднання з базою, а в e2e це не так. У браузерному тесті застосунок — окремий процес зі своїм пулом з'єднань, а Playwright лише керує браузером; транзакція, відкрита з коду тесту, для сервера — чуже незакомічене з'єднання, змін якого він через ізоляцію транзакцій навіть не бачить. Тому все, що застосунок пише під час тесту, іде повз твій BEGIN, і ROLLBACK нічого з цього не відкотить. Відкат — прийом для інтеграційних чи модульних тестів, де застосунок піднято в тому ж процесі й ти інжектиш у нього те саме з'єднання. Для браузерних e2e лишаються унікальні дані або виділена база на воркер.

Чим TRUNCATE відрізняється від DELETE, і що роблять RESTART IDENTITY та CASCADE?

TRUNCATE стирає всі рядки таблиці, не йдучи по них по одному, тому він помітно швидший за DELETE без WHERE і бере ексклюзивне блокування. RESTART IDENTITY додатково скидає лічильники автоінкремента, щоб після очистки ідентифікатори знову починалися з відомого значення й були передбачувані між прогонами. CASCADE поширює очистку на таблиці, що посилаються на цю через зовнішній ключ, — без нього TRUNCATE відмовиться чіпати таблицю, на яку є посилання ззовні (обидві опції — синтаксис PostgreSQL). Разом це зручний спосіб повернути тестову базу до чистого відомого стану між тестами. Але саме через руйнівність (ексклюзивне блокування, стирання всього) TRUNCATE припустимий лише на виділеній тестовій базі.

Чи можна підстрахувати прибирання через TRUNCATE транзакцією і ROLLBACK?

Тільки якщо знаєш, яка СУБД під стендом, — і це рівно та розбіжність, на якій втрачають дані. У PostgreSQL TRUNCATE транзакційно безпечний щодо даних у таблицях: якщо транзакція навколо не закомітилась, усічення буде коректно відкочене, і разом із ним відкотиться навіть RESTART IDENTITY. У MySQL/InnoDB усе навпаки: TRUNCATE спричиняє неявний commit і відкату не підлягає, а сам довідник MySQL класифікує його як DDL, а не DML. Тому прибирання, написане як BEGIN → TRUNCATE → перевірка → ROLLBACK, на PostgreSQL-стенді відпрацює як задумано, а на MySQL-стенді знищить дані незворотно — і жодної помилки при цьому не буде, тобто скрипт виглядатиме успішним. Практичний висновок: на MySQL страховки немає взагалі, TRUNCATE там дозволений лише на базі, яку не шкода втратити цілком.

Тести падають під паралеллю на спільній базі. Чому і що робити?

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

Як підключити pg чи mysql2 до Playwright і чому саме фікстурою зі скоупом воркера?

Щоб сідати чи перевіряти дані напряму, тесту потрібен драйвер: pg (node-postgres) для PostgreSQL, mysql2 для MySQL. Найзручніше підвісити пул з'єднань як фікстуру Playwright зі скоупом воркера (scope: 'worker'): тоді пул відкривається раз на воркер, перевикористовується всіма тестами цього воркера й закривається під час прибирання через pool.end(). Скоуп воркера, а не тесту, важливий тому, що відкривати й закривати з'єднання на кожен тест — марна витрата, а незакритий пул ще й не дасть процесу завершитися. Рядок підключення беруть з оточення (process.env.TEST_DATABASE_URL), а не хардкодять, щоб той самий код працював локально й у CI.

Чому в тесті потрібні параметризовані запити, а не склеювання рядків, якщо дані все одно свої?

Бо це не лише про SQL-інʼєкції. Так, у тесті дані підконтрольні, і про інʼєкцію можна не думати, але параметризований запит ще й коректно екранує лапки, дати й NULL, які склеювання рядків спокійно ламає: апостроф у прізвищі, дата в чужому форматі, NULL замість рядка "NULL". У pg плейсхолдери нумеровані ($1), у mysql2 — знак питання (?); драйвер сам подбає, щоб значення потрапило в запит коректно. Це надійніше, читабельніше й дешевше, ніж вручну ліпити рядок, тому параметризація — дефолт навіть там, де безпека не турбує.

Навіщо давати тесту read-only з'єднання на спільному стенді?

Щоб тест технічно не міг зіпсувати спільний стенд необережним запитом. На прод-подібних чи спільних середовищах з'єднання тесту роблять окремим користувачем БД лише з правом SELECT. Тоді випадковий UPDATE без WHERE чи помилковий DELETE просто не виконається — база відмовить за браком прав, замість тихо знести дані під іншими прогонами. Це дисципліна «мінімально потрібних прав»: тест, який лише читає й асертить стан, не потребує запису, тож і не повинен його мати. Права на запис лишають окремому сідеру на ізольованих базах, де руйнувати нема кому заважати.

Коли assert напряму в БД доречний, а коли це антипатерн?

Дефолт — перевіряти те, що бачить користувач, там, де він це бачить: UI або відповідь API. Assert у БД прив'язує тест до схеми — перейменували стовпець, денормалізували поле, і тест червоний, хоча продукт працює; дублювати в базі те, що вже видно у відповіді API, — зайве й крихко. Виправданий assert у БД лише там, де є побічний ефект, невидимий зовні: запис в аудит-лог, прапорець м'якого видалення (soft delete), результат фонового джоба, денормалізований лічильник, що має зійтися, або службове поле, яке застосунок зберігає, але ніде не показує. Тобто база — оракул для того, що інакше не спостерігається, а не другий канал для перевірки видимого.

Перевіряєш у базі результат фонового джоба. Чому sleep — погана ідея, а полінг — добра?

Бо фоновий джоб пише в базу асинхронно, і момент, коли рядок з'явиться, наперед невідомий. Фіксований sleep — це ставка навмання: поставив мало — тест червоніє, бо джоб ще не дописав; поставив із запасом — сюїта тупо гальмує на кожному прогоні, навіть коли джоб відпрацював миттєво. Полінг (poll) із таймаутом знімає обидві проблеми: запитуєш таблицю в циклі, доки потрібний рядок не з'явиться або не вийде час, тож тест іде далі рівно тоді, коли ефект настав, і чесно падає, якщо не настав за розумний строк. Це той самий принцип «чекай на умову, а не на годинник», що й у ретраях UI-очікувань.

Чому в CI не можна підмінити базу на SQLite чи мок «щоб швидше»?

Бо це підриває довіру до всієї сюїти. SQLite — інший діалект: інша поведінка NULL, типів, транзакцій, блокувань і функцій, тож тести зеленітимуть там, де реальний Postgres упав би, і навпаки. Ти тестуєш не ту СУБД, що поїде в прод, а її віддалену родичку, і найцікавіші баги — саме на стиках діалектів — просто не проявляться. Правильно — підняти справжню СУБД у контейнері: сервіс postgres у docker compose поруч із застосунком або блок services: у GitHub Actions, який дає живу PostgreSQL на час джоба. Швидкість тут не аргумент проти реалізму: контейнер стартує за секунди, а фальшива зелень коштує дорожче.

Що таке testcontainers і що вони дають понад звичайний сервіс БД у CI?

testcontainers — бібліотека, що піднімає одноразові контейнери прямо з коду тесту. Замість зовні налаштованого сервісу тест сам стартує свіжу PostgreSQL на випадковому порту, отримує рядок підключення, а після прогону контейнер автоматично прибирається. Плюс — повна ізоляція й відтворюваність: кожен прогін на чистій базі, локально й у CI однаково, без ручного docker compose і без ризику, що попередній прогін лишив сміття. Мінус — старт контейнера додає секунди, тож скоуп фікстури (на сюїту чи на воркер) обирають свідомо, щоб не піднімати базу заново на кожен тест. Коротко: у CI база має бути реальною СУБД, а testcontainers роблять її ще й одноразовою.

Можна залити дамп продакшену на стейдж «для реалістичності»? Що відповісти?

Ні, сирий прод-дамп на стейдж — заборонений дефолт, і «так, зручно» тут червоний прапор. Дамп містить персональні дані реальних людей (імена, email, телефони, платіжки), а переливання їх у менш захищене тестове середовище — це витік і порушення приватності, під GDPR зокрема. Якщо прод-подібні обсяги все ж потрібні, дані анонімізують перед завантаженням: маскування (masking) — заміна чутливих значень фіктивними того ж формату; псевдонімізація — стабільна заміна за ключем; підмножина (subset) — узгоджений зріз зі збереженою цілісністю; або взагалі синтетичні дані з фабрик і faker. Найпростіший і найбезпечніший шлях у більшості випадків — не морочитися з дампом, а будувати стан синтетикою: жодних PII, повний контроль, відтворюваність.

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

Маскування замінює чутливе значення фіктивним того ж формату — email на згенерований, номер картки на тестовий — і робить це незалежно в кожному місці. Псевдонімізація — стабільна заміна за ключем: той самий реальний користувач в усіх таблицях маскується однаково, тож user_id, замаскований в одній таблиці, замінюється тим самим значенням у всіх, що на нього посилаються. Різниця критична саме через посилальну цілісність: якщо просто «замаскувати» ключ по-різному в різних таблицях, зв'язки за зовнішнім ключем розваляться й отримаєш сирітські записи, яких у проді не було. Тому для реляційних даних потрібне саме стабільне, консистентне псевдо, а не незалежне маскування кожної клітинки.

Три кейси, де тестові дані вирішують, стабільна сюїта чи флак: сідінг фабрикою з унікальними даними поверх worker-scoped пулу pg, assert невидимого зовні ефекту (soft delete) через полінг, і діагностика класики «зелений наодинці, червоний у наборі». Скрізь — що робити і чому саме так.

Кейс 1. Фабрика + унікальні дані поверх worker-scoped пулу

Мета — сідати стан так, щоб два воркери на спільній базі не билися за одні рядки. Пул pg підвішуємо фікстурою зі скоупом воркера (відкрити раз, закрити під час прибирання), а фабрика вшиває номер воркера в унікальний ключ, тож кожен воркер працює у власному неймспейсі.

import { test as base } from '@playwright/test';
import { Pool } from 'pg';
import { faker } from '@faker-js/faker';

type WorkerFixtures = { db: Pool };

export const test = base.extend<object, WorkerFixtures>({
  db: [async ({}, use) => {
    const pool = new Pool({ connectionString: process.env.TEST_DATABASE_URL });
    await use(pool);
    await pool.end(); // тірдаун: без цього процес не завершиться
  }, { scope: 'worker' }],
});

// фабрика: унікальний email із номером воркера + faker, дефолти з перевизначенням
async function createUser(
  db: Pool,
  workerIndex: number,
  over: Partial<{ role: string }> = {},
) {
  const email = `w${workerIndex}_${Date.now()}_${faker.string.uuid()}@test.local`;
  const role = over.role ?? 'user';
  const { rows } = await db.query(
    'INSERT INTO users (email, role) VALUES ($1, $2) RETURNING id, email',
    [email, role], // параметризовано: жодного склеювання рядків
  );
  return rows[0];
}

test('адмін бачить панель керування', async ({ db, page }, testInfo) => {
  const admin = await createUser(db, testInfo.workerIndex, { role: 'admin' });
  // ... логін під admin.email, перевірка UI
});

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

• Скоуп воркера, а не тесту. Пул відкривається раз на воркер і перевикористовується всіма його тестами; відкривати з'єднання на кожен тест — марно, а незакритий пул завісить процес. pool.end() під час прибирання обов'язковий.
• w${workerIndex}_... у ключі — це і є неймспейсинг. Кожен воркер живе у власному неймспейсі, тож TRUNCATE не потрібен і паралель безпечна навіть на спільній базі. Ціна — база засмічується, тож десь поруч має бути нічне прибирання або TTL, а не teardown усередині тесту.
• INSERT тут виправданий, бо стан простий і схема відома. Якби створення користувача тягло хешування пароля, тригери чи записи у зв'язані таблиці — правильніше було б сідати через API/бекдор, щоб не породити неможливий стан.
• Параметри $1, $2, а не конкатенація. Це не лише про інʼєкцію (дані свої), а про коректне екранування — апостроф у ролі чи NULL не зламають запит.

Кейс 2. Assert невидимого ефекту: soft delete через полінг

Кнопка «Видалити» в UI лише ховає запис — фізично рядок лишається з прапорцем deleted_at. Цього ефекту в інтерфейсі не видно, тож саме тут assert у БД доречний. А оскільки видалення може оброблятися асинхронно, чекаємо полінгом, а не sleep.

import { expect } from '@playwright/test';
import { test } from './fixtures'; // розширений test із кейсу 1 (фікстура db)

// полінг: питаємо базу, доки умова не справдиться або не вийде час
async function pollUntil<T>(
  fn: () => Promise<T | null>,
  { timeout = 5000, interval = 200 } = {},
): Promise<T> {
  const deadline = Date.now() + timeout;
  for (;;) {
    const value = await fn();
    if (value !== null) return value;
    if (Date.now() > deadline) throw new Error('умова не настала за таймаут');
    await new Promise((r) => setTimeout(r, interval));
  }
}

test('видалення — це soft delete, рядок лишається з deleted_at', async ({ db, page }) => {
  // ... створили запис (маємо orderId), натиснули «Видалити» в UI

  const row = await pollUntil(async () => {
    const { rows } = await db.query(
      'SELECT id, deleted_at FROM orders WHERE id = $1',
      [orderId],
    );
    // чекаємо саме на проставлений deleted_at, а не на зникнення рядка
    return rows[0]?.deleted_at ? rows[0] : null;
  });

  expect(row.deleted_at).not.toBeNull(); // рядок є, але позначений видаленим
});

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

• Assert у БД тут не дубль, а єдиний оракул. UI показує «видалено», API повертає порожньо — сам факт, що рядок фізично лишився й лише позначений, зовні не спостерігається. Це рівно той випадок, коли база доречна.
• Полінг, а не sleep. Фіксована пауза — ставка навмання: мало — червоно, багато — сюїта гальмує щоразу. Полінг іде далі рівно тоді, коли ефект настав, і чесно падає за таймаутом, якщо не настав.
• Обережно з тим, що саме асертиш. Перевіряй інваріант soft delete (deleted_at проставлено), а не «рядок зник» — інакше тест сплутає м'яке видалення з жорстким і зловить не той баг.

Кейс 3. «Зелений наодинці, червоний у наборі» — діагностика

Тест стабільно проходить сам, але «іноді» падає в повному прогоні. Спокуса — списати на таймінги браузера й накинути ретраїв. Майже завжди причина інша: конфлікт за спільний стан. Ось як звузити діагноз замість здогадів.

Порядок дій, а не гадання:

• Спочатку відтвори. Прожени сюїту з --workers=1: якщо позеленіла — це конфлікт за паралель, а не таймінг. Прожени проблемний тест ізольовано: зелений — винен сусід або спільний стан.
• Знайди спільний рядок. Пошукай фіксовані email/ID/назви в сідах і фабриках — саме вони перетинаються між тестами; заміни на унікальні per-worker.
• Не лікуй ретраєм. Ретрай ховає конфлікт за даними, але не прибирає його: сюїта лишається крихкою, а причина — недіагностованою. Ретрай доречний для справжньої мережевої нестабільності, не для спільного стану.
• Не сподівайся, що прибирання «саме відкотиться». Обгортка BEGIN/ROLLBACK навколо TRUNCATE рятує лише на PostgreSQL, де усічення відкочується разом із незакоміченою транзакцією. На MySQL/InnoDB TRUNCATE дає неявний commit — рядок «Дані зникають посеред тесту» з таблиці вище там стається навіть тоді, коли прибирання начебто було в транзакції.

Сіди, фікстури, фабрики

• Розрізняю сід (фіксований набір на все середовище), фікстуру (стан під конкретний тест) і фабрику (код, що будує сутність із дефолтами).
• Знаю, що фікстура в Playwright — ще й механізм фреймворку: віддає готовий об'єкт і прибирає його після тесту.

Сідінг: через API чи напряму в БД

• Можу пояснити дефолт: готуй стан через API/бекдор, лізь у базу напряму лише там, де API станом керувати не дає.
• Знаю тредоф API проти прямого INSERT: API дає реальну валідацію, похідні поля, тригери й консистентність і переживає зміну схеми, а прямий INSERT швидкий і всесильний, але обходить логіку й прив'язує сід до схеми.
• Розумію, що таке «неможливий стан» (замовлення без позицій, підписка без користувача) і чому це кривий сід, а не баг продукту.

Ізоляція тестів

• Знаю три підходи й межу кожного: унікальні дані, відкат транзакції, TRUNCATE.
• Розумію, чому унікальні дані (неймспейсинг) — єдиний підхід, безпечний на спільній базі й під паралеллю, і що його ціна — засмічена база.
• Можу пояснити, чому відкат транзакції працює лише коли код і тест ділять одне з'єднання, і тому не годиться для браузерних e2e.
• Знаю, що робить TRUNCATE (RESTART IDENTITY скидає автоінкремент, CASCADE зачищає залежні за FK) і чому він припустимий лише на виділеній базі, ніколи — на спільному стейджі чи проді.
• Знаю, що TRUNCATE у транзакції — не страховка: у PostgreSQL усічення відкотиться, якщо транзакція не закомітилась, а в MySQL/InnoDB воно дає неявний commit, і ROLLBACK після нього не поверне нічого й помилки не покаже.

Паралель і спільна база

• Тримаю в голові головне правило й три виходи: паралель і руйнівне прибирання спільної бази несумісні — унікальні дані на воркер, база/схема на воркер або серіалізація групи як останній засіб.
• Розумію, чому «додамо ретраїв» на конфлікт за дані — маскування, а не лікування.

З'єднання з БД у коді тесту

• Знаю драйвери й чому пул підвішують фікстурою зі скоупом воркера: pg (node-postgres) для PostgreSQL, mysql2 для MySQL; пул відкривається раз на воркер і закривається під час прибирання через pool.end().
• Пишу лише параметризовані запити ($1 у pg, ? у mysql2) — не лише проти інʼєкції, а й заради коректного екранування лапок, дат і NULL.
• Розумію дисципліну read-only: на спільних стендах з'єднання тесту — окремий користувач лише з SELECT.

Assert у БД

• Знаю дефолт і коли виняток: перевіряй видиме в UI/API (assert у БД прив'язує до схеми), а сам assert у БД доречний для невидимих ефектів — аудит-лог, soft delete, фонові джоби, денормалізовані агрегати, службові поля.
• Розумію, чому фоновий ефект перевіряють полінгом із таймаутом, а не sleep.

БД у CI і прод-дані

• Знаю, чому в CI база має бути реальною СУБД у контейнері, а не SQLite/моком (інший діалект — фальшива зелень).
• Розумію, що дають testcontainers: одноразова, ізольована БД із коду тесту ціною секунд на старт.
• Можу пояснити, чому сирий прод-дамп на стейдж — витік PII (GDPR), а не «реалістичність».
• Розрізняю маскування, псевдонімізацію (стабільну за ключем), підмножину й синтетику — і чому цілісність між таблицями критична.