Тестові дані та стан в API-тестах

Тест робить POST, отримує 202, одразу читає GET — і бачить 404. Що сталося?

Найімовірніше це не баг застосунку, а кінцева узгодженість (eventual consistency): між записом і читанням у розподіленій системі є вікно, коли створене «ще не існує» для того шляху, яким ти його читаєш. Запис міг піти в майстер-базу, а GET обслужила репліка, яка ще не отримала оновлення; або дані лягли в основне сховище, але ще не потрапили в пошуковий індекс чи кеш. Тест просто випередив систему: спитав раніше, ніж запис доїхав до того сховища, з якого йде читання. Перше, що робить сильний кандидат, — не кидається правити тест хардкодом, а з'ясовує, який код віддає ендпоінт і синхронна операція чи асинхронна, і замінює гонку полінгом на конкретну умову. Баг-репорт «POST не записує» тут майже завжди хибний — але тільки поки код відповіді 202: якби POST віддав 201, той самий симптом був би вже порушенням контракту статус-коду.

Що означає код 202 Accepted і чим він відрізняється від 201 Created?

201 Created — ресурс уже створено, його можна одразу читати. 202 Accepted — сервер прийняв запит, але обробка ще триває: результат буде колись потім, а не в цю мить. Тобто 202 — це відкритий сигнал сервера «не читай наосліп, я ще не готовий», типовий для операцій через чергу повідомлень. Для тесту різниця практична: побачив 202 — не став асерт на GET одразу, а чекай появи даних полінгом. А 201 навпаки гарантує видимість: ресурс створюється до повернення відповіді й має бути досяжним за URL запиту або за Location, тож 201 із наступним 404 — це дефект постачальника або неправильно обраний код, а не привід ставити полінг.

Звідки взагалі береться затримка між записом і читанням?

Чотири типові джерела. Черги повідомлень: POST лише публікує подію (Kafka, RabbitMQ) і відповідає 202, а справжня обробка наздоганяє асинхронно. Репліки на читання: писали в майстер, а читає GET з репліки, яка відстає на replication lag. Пошукові індекси: у базі об'єкт уже є, а Elasticsearch перебудовує індекс власним циклом — типово порядку секунди. Кеші: відповідь для списку вже закешована, тож новинка з'явиться там лише після інвалідації. Спільна риса всіх чотирьох — читання йде не тим шляхом, що запис, тож між ними виникає вікно неузгодженості.

Чому sleep(2000) перед перевіркою — погане рішення?

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

Що таке полінг і чим він кращий за sleep?

Полінг (polling) — це періодичне перепитування системи, доки умова не справдиться, з жорстким верхнім таймаутом. Замість чекати абстрактні «дві секунди» тест чекає на конкретний спостережуваний факт: статус 200, поле status: "processed", наявність елемента у списку. Щойно дані фактично готові — тест рушає далі; фейл настає лише після вичерпання таймаута. У Playwright це expect.poll або toPass з таймаутом та інтервалами. Полінг — API-варіант «розумного очікування», того самого, що в браузері дає автоочікування Playwright: чекаємо на стан, а не на годинник.

Які властивості роблять полінг надійним?

Три. Умова, а не час: чекаємо на спостережуваний факт, а не на кількість секунд. Верхній таймаут: без стелі полінг здатен висіти вічно, а зависання діагностувати важче, ніж падіння; таймаут конвертує «система не відповідає» в чесний фейл із зрозумілим стектрейсом. Ідемпотентна перевірка: функція всередині полінгу має бути безпечною для багаторазового виклику, тобто тільки читання, без побічних ефектів. Останнє критичне: полити POST не можна — на кожній ітерації створиш нове замовлення й отримаєш десять дублів замість одного. Полінг завжди накручують на GET.

Як ти готуєш тестові дані — через публічний API чи прямо в базу?

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

Коли виправданий прямий запис у базу в обхід застосунку?

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

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

Це спеціальний ендпоінт (наприклад, POST /test/seed), доступний лише на не-продакшн-середовищах, який ставить потрібний стан валідно, але швидко — в обхід повільного публічного флоу, але не в обхід бізнес-правил. Він розв'язує конфлікт між двома крайнощами: сідінг через публічний API валідний, але повільний і не завжди може поставити складний стан; прямий INSERT швидкий, але ризикує порушити інваріанти. Бекдор дає золоту середину — застосунок сам будує стан коректно, але тобі не треба проганяти десяток реальних кроків. Ключова умова безпеки: такий ендпоінт ніколи не має бути доступним у проді.

Як ти ізолюєш тести, щоб вони не заважали одне одному?

Базовий принцип — власність над даними: кожен тест володіє своїми даними й не спирається на чужі. Практично це три рівні. Унікальні ідентифікатори: ніколи не хардкодь email: "test@test.com" — генеруй унікальне значення на кожен прогін (таймстемп плюс випадковий суфікс), інакше другий паралельний запуск отримає конфлікт унікальності. Окремий акаунт на тест або воркер: якщо тести змінюють профіль, баланс, налаштування — дай кожному свого користувача, тоді паралельні тести фізично не бачать даних одне одного. Окремий tenant у мультитенантних системах — найсильніша ізоляція. Ізоляція через дані зазвичай дешевша й надійніша за ізоляцію через прибирання — з поправкою, що перебудова бази на кожен прогін теж коштує часу.

Окремий акаунт і окремий tenant — у чому різниця й де ізоляція сильніша?

Окремий акаунт розділяє записи одного користувача: кожному тесту свій юзер, тож вони не затирають одне одному профіль чи баланс. Окремий tenant (тенант — організація, робочий простір у multi-tenant SaaS) розділяє значно більше: не лише записи, а й довідники, ліміти, налаштування — усе, що система тримає per-tenant. Один тенант не бачить даних іншого за побудовою системи, а не завдяки дисципліні тесту. Тому tenant — найсильніший рівень ізоляції: навіть глобальні для акаунта сутності в різних тенантів різні. Мінус — не кожна система мультитенантна, і виділити тесту чистий tenant буває дорожче, ніж просто нового юзера.

Чому не варто спиратися лише на прибирання в afterEach?

Головна вада стратегії прибирання — не залишки, а діагностованість: баг сидить в одному тесті, а червоніє інший, і знайти справжню причину важко. Якщо ж тест сам не побудував собі початковий стан, видно одразу, який саме тест зламаний. Унікальні дані працюють у цю ж користь: навіть якщо попередній прогін лишив по собі юзера з email від старого таймстемпу, новий прогін згенерує інший email і просто його не зачепить. Тобто унікальність — це перша лінія оборони. Прибирання теж потрібне, щоб стенд не заростав сміттям, але покладатися тільки на нього небезпечно.

Що робить тест недетермінованим і як це лікувати?

Тест детермінований, якщо на незмінному вході дає незмінний результат. Канонічний перелік джерел недетермінізму — брак ізоляції, асинхронність, віддалені сервіси, час і витоки ресурсів; на рівні API найчастіше вилазять недетерміновані зовнішні залежності. Три класи: сторонні API (платіжний шлюз, курс валют, погода) — твій зелений/червоний починає залежати від чужого аптайму; час (логіка «підписка активна ще 3 дні», «купон діє до кінця місяця») — тест, зелений у липні, червоніє 1 числа наступного місяця; випадковість (промокоди, A/B-когорти, рандомні ID). Лікування: мокати залежність контрольованим дублером, використовувати офіційний sandbox провайдера з «магічними» значеннями, а час контролювати через дані — ставити expiresAt явно на рік уперед, а не підлаштовуватися під «сьогодні».

Тест залежить від сьогоднішньої дати. Як зробити його стабільним?

З API-тесту ти зазвичай не можеш перевести годинник сервера, тому не намагайся «підлаштуватися під сьогодні» — навпаки, задай дату явно в даних. Замість створювати підписку й сподіватися, що вона активна саме зараз, створюй її з expiresAt за рік уперед; замість покладатися на «поточний купон» став купон із датою дії в майбутньому. Тоді результат перевірки не залежить від дня прогону: інваріант «активна підписка видима» перевіряється на даних, які будуть активними завжди. Це і є «керувати часом через дані, а не через тест» — зсув відповідальності з непідконтрольного годинника на підконтрольне поле в сіді.

Чому асерт «GET /users повертає рівно 5 записів» приречений на спільному стенді?

Бо на спільному стенді (staging) одночасно працюють автотести, мануальники, розробники й демо для замовника — користувачів то 5, то 47, і точна кількість постійно змінюється. Асерт на глобальний лічильник ловить не поведінку застосунку, а випадковий зріз бази в момент прогону, тож він флакне без жодного бага. Правильний підхід — перевіряти наявність свого створеного запису у відповіді, а не точну кількість усіх: створив юзера з унікальним email, а потім асертиш, що він є у списку. Це загальна дисципліна спільного оточення: тест відповідає лише за дані, які створив сам, і не робить припущень про решту стенду.

Тест зелений локально, а в CI падає з 409 або дублями. Де копати?

Симптом майже завжди вказує на дизайн тестових даних і ізоляцію, а не на баг продукту. 409 Conflict на повторному прогоні означає, що дані з попереднього запуску лишилися (прибирання не спрацювало) або тест хардкодить неунікальне значення — лікується унікальними ідентифікаторами на кожен прогін. Дублі під паралелізмом — це гонки між воркерами: два паралельних тести беруть «перший вільний промокод» і хапають один і той самий; вирішується виділенням даних на воркер. Те, що локально зелено, а в CI ні, — типова ознака саме конкурентності (concurrency) — перекриття операцій у часі — і спільного стану: локально тести йдуть послідовно й по черзі, а в пайплайні паралельно гатять в одні дані. Копай ізоляцію, а не застосунок.

Ідеал — свіжа база на кожен прогін. Що робити, коли є лише один спільний staging?

Прийняти, що ти в спільному оточенні (shared environment), і жити за його правилами. Не залежати від передіснуючих даних: не припускай, що «юзер id=1 — це адмін Іван», бо хтось міг його перейменувати чи видалити. Не асертити глобальні лічильники — тільки наявність свого запису. Виділяти дані на воркер, щоб прибрати гонки. А якщо клас «чужих даних» болить надто сильно, радикальний вихід — ефемерні середовища: піднімати чисте оточення на кожен прогін (докеризована база, ефемерний namespace). Це дорожче в інфраструктурі, але прибирає весь клас проблем спільного стенду одним рішенням. Проста дисципліна на кожен день: тест відповідає лише за створене ним.

Що таке ідемпотентність запиту і чому вона важлива для стабільності тестів?

Ідемпотентність — властивість запиту давати той самий результат при повторному виклику: повторний PUT чи DELETE не змінює стан удруге, а POST роблять ідемпотентним через Idempotency-Key. Для тестів це важливо на двох рівнях. По-перше, ретрай тесту чи мережевий збій без ідемпотентності створює дублі: тест «переслав» POST, і замість одного замовлення стало два. По-друге, функція всередині полінгу мусить бути ідемпотентною (лише читання) — саме тому полять GET, а не POST. Тобто ідемпотентність — це те, що робить безпечними і повторні спроби, і саме очікування на умову.

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

Кейс 1. POST → 202, а GET дає 404: полінг замість sleep

Сценарій із життя: тест створює замовлення, сервер відповідає 202 Accepted (обробка пішла в чергу), тест одразу читає GET /orders/{id} — і ловить 404. Розробник каже «у мене все створюється», і він має рацію: за секунду замовлення на місці. Проблема — тест поставив питання раніше, ніж репліка/черга встигли застосувати запис.

Найгірша реакція — заткнути паузою:

// Погано: фіксована пауза — або флак на завантаженому CI, або марна трата часу
const created = await request.post('/api/orders', { data: { sku: 'A-1', qty: 2 } });
const { id } = await created.json();

await new Promise((r) => setTimeout(r, 2000)); // 2с наосліп
const res = await request.get(`/api/orders/${id}`);
expect(res.status()).toBe(200);

Правильно — чекати саме на умову, з верхнім таймаутом:

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

test('замовлення стає видимим після асинхронної обробки', async ({ request }) => {
  const created = await request.post('/api/orders', { data: { sku: 'A-1', qty: 2 } });
  expect(created.status()).toBe(202); // прийнято, обробляю
  const { id } = await created.json();

  // полінг на конкретний факт: GET віддав 200
  await expect
    .poll(async () => (await request.get(`/api/orders/${id}`)).status(), {
      timeout: 10_000,
      intervals: [250, 500, 1000],
    })
    .toBe(200);

  // а тепер уже безпечно асертити вміст
  const res = await request.get(`/api/orders/${id}`);
  expect(await res.json()).toMatchObject({ id, status: 'processed' });
});

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

• 202 замість 201 — це не помилка, а сигнал. Сервер прямо каже «результат ще не готовий, не читай наосліп». Асерт GET одразу після такого POST — гонка за побудовою.
• Полять GET, а не POST. Функція всередині expect.poll викликається багато разів, тож вона мусить бути ідемпотентною — тільки читання. Якби всередину поставили POST, кожна ітерація створювала б нове замовлення.
• Умова, а не час. Чекаємо на status() === 200 (спостережуваний факт), а не на «дві секунди». Тест іде далі рівно тоді, коли дані з'явилися.
• Верхній таймаут обов'язковий. Без timeout полінг зависне назавжди, якщо дані так і не з'являться. Таймаут перетворює «система тупить нескінченно» на чесний фейл зі стектрейсом.

Кейс 2. Сідінг передумови через API з унікальними даними

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

Надійний варіант — сідити через ті самі ендпоінти, що й реальний клієнт, з унікальними даними на кожен прогін:

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

test('оплачене замовлення видиме у списку користувача', async ({ request }) => {
  // унікальний email — жодних конфліктів між паралельними воркерами
  const email = `qa+${Date.now()}-${faker.string.alphanumeric(6)}@example.com`;

  // сід через публічний API: застосунок сам ставить валідний стан
  const user = await request.post('/api/users', { data: { email, role: 'customer' } });
  expect(user.status()).toBe(201);
  const { id: userId } = await user.json();

  const order = await request.post('/api/orders', {
    data: { userId, sku: 'A-1', qty: 1, status: 'paid' },
  });
  expect(order.status()).toBe(201);
  const { id: orderId } = await order.json();

  // асерт на НАЯВНІСТЬ свого запису, а не на кількість усіх
  const list = await request.get(`/api/users/${userId}/orders`);
  const orders = await list.json();
  expect(orders.some((o) => o.id === orderId)).toBe(true);
});

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

• email унікальний на кожен прогін. Date.now() плюс випадковий суфікс прибирають конфлікт унікальності — перша лінія оборони проти зіткнень, надійніша за прибирання в afterEach.
• Сід іде через API, а не INSERT. Застосунок сам будує валідний стан: правильні зовнішні ключі, обчислені поля, події в черзі. Прямий запис у базу цього не гарантує.
• Асерт на наявність свого запису. orders.some(...) перевіряє, що мій ордер у списку, а не «рівно N замовлень». На спільному стенді точна кількість постійно змінюється, тож асерт на лічильник флакне без бага.
• Коли API замало. Якщо стан дорогий чи недосяжний (історичні дані, «зіпсований» запис), тоді розглядають тест-бекдор POST /test/seed на не-проді — валідно, але швидко; прямий INSERT — крайній випадок з усвідомленням ризику.

Кейс 3. Детермінізм: явна дата в сіді замість реального годинника

Тест перевіряє інваріант «активна підписка видима в кабінеті». Наївна реалізація створює підписку «на 30 днів» і сподівається, що зараз вона активна. Такий тест зелений у липні й червоніє на межі місяця чи коли CI підхопить іншу таймзону — класична недетермінована залежність від поточної дати.

З API-тесту ти зазвичай не можеш перевести годинник сервера, тож керуй часом через дані: став дату явно й із запасом.

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

test('активна підписка видима незалежно від дня прогону', async ({ request }) => {
  // не «сьогодні + 30 днів», а явна дата далеко в майбутньому
  const expiresAt = new Date('2999-01-01T00:00:00Z').toISOString();

  const sub = await request.post('/api/subscriptions', {
    data: { plan: 'pro', expiresAt },
  });
  expect(sub.status()).toBe(201);
  const { id } = await sub.json();

  const res = await request.get(`/api/subscriptions/${id}`);
  expect(await res.json()).toMatchObject({ id, status: 'active' });
});

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

• Дата задана явно, а не відносно «сьогодні». Інваріант «активна підписка активна» перевіряється на даних, які будуть активними завжди, тож результат не залежить від дня прогону чи таймзони агента.
• Зсув відповідальності. Замість підлаштовуватися під непідконтрольний годинник сервера ти ставиш підконтрольне поле expiresAt у сіді. Те саме працює для купонів, промо, тріалів.
• Сторонні залежності — окрема історія. Якщо в грі платіжний шлюз чи курс валют, дату даними не полагодиш — там потрібен мок або офіційний sandbox провайдера з «магічними» значеннями (докладніше — у главі про мокання залежностей).
• Не забувай про ідемпотентність. Якщо тест ретраїться, повторний POST без Idempotency-Key може створити дубль підписки; для критичних створень варто передбачити ключ ідемпотентності.

Eventual consistency і стан

• Розумію, що в розподіленій системі між записом і читанням є вікно неузгодженості — створене «ще не існує» для того шляху, яким його читаю.
• Знаю чотири джерела лагу: черги повідомлень, репліки на читання (replication lag), пошукові індекси, кеші.
• Можу пояснити, чому 202 Accepted — це відкритий сигнал «результат ще не готовий», на відміну від 201 Created, який обіцяє вже створений і досяжний ресурс.
• Знаю, що несподіваний 404 після POST з 202 часто маскує не баг створення, а читання з репліки/індексу з лагом; після 201 той самий симптом — це вже порушення контракту статус-коду.

Полінг проти sleep

• Можу пояснити, чому фіксований sleep програє в обидва боки: занадто короткий дає флак, занадто довгий тринькає час усієї сюїти.
• Знаю три властивості надійного полінгу: умова замість часу, верхній таймаут, ідемпотентна перевірка.
• Розумію, чому полити POST не можна — на кожній ітерації створиться новий запис; полять лише GET.

Сідінг тестових даних

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

Ізоляція через власність над даними

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

Детермінізм зовнішніх залежностей

• Знаю канонічний перелік джерел недетермінізму (брак ізоляції, асинхронність, віддалені сервіси, час, витоки ресурсів) і його API-зріз: сторонні API, час, випадковість у даних.
• Можу пояснити стратегії: мокати залежність, використати офіційний sandbox, керувати часом через дані.
• Знаю, що ідемпотентність повторних запитів (Idempotency-Key, повторний PUT/DELETE) захищає від дублів при ретраях.

Спільне оточення і чужі дані

• Розумію пастку залежності від передіснуючих даних: «юзер id=1 — це адмін Іван» падає, коли його перейменували.
• Знаю, чому асерт на глобальний лічильник («рівно 5 користувачів») приречений на спільному стенді.
• Можу пояснити гонки між воркерами («перший вільний промокод») і що лікуються вони виділенням даних на воркер.