Практичні сценарії AQA: флак і синхронізація

Що таке flaky-тест і чому він виникає?

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

Чому sleep(3) — погана заміна очікуванню?

Жорстка пауза синхронізується з годинником, а не з застосунком — вона не знає, готова система чи ні. Тому вона програє двічі: на повільному CI трьох секунд може не вистачити, і тест флакне; на швидкій машині ти щоразу марно чекаєш повний інтервал, і сотні таких пауз перетворюють десятихвилинний прогін на годинний. Розумне очікування натомість опитує реальну умову й завершується в ту саму мілісекунду, коли вона стала істинною, а якщо ні — падає з чіткою причиною в межах таймауту. Єдиний умовно-виправданий випадок для sleep — коли треба переконатися у відсутності зміни («після дії нічого не має статися»), бо чекати на «нічого» нема як; але й тут краще підтвердити стан через прикладний сигнал.

Тест падає з NoSuchElementException одразу після відкриття сторінки. У чому причина і як виправити?

Причина в тому, що пошук елемента виконується миттєво в момент виклику, а елемент зʼявляється в DOM пізніше — після асинхронного запиту й домальовування розмітки фреймворком. У Selenium це лікується явним очікуванням: WebDriverWait з умовою until.elementLocated дає застосунку час доробити своє. У Playwright проблема знята архітектурно: локатор лінивий, і дія на кшталт await page.locator('#save').click() сама повторює спроби до таймауту, поки елемент не зʼявиться і не стане придатним до дії. Ключова думка, яку варто озвучити: локатор — це не сам елемент, а рецепт, як його знайти; знаходити треба в момент дії, а не наперед.

Чим explicit wait відрізняється від auto-wait, і що таке implicit wait?

Явне очікування (explicit wait) — це коли інженер сам пише умову й таймаут: «чекай, поки елемент стане видимим, до 10 секунд» — класика Selenium через WebDriverWait + expected_conditions. Авто-очікування (auto-wait) — коли інструмент перед кожною дією сам перевіряє набір умов актуальності й перечікує до таймауту; так працює Playwright і частково Cypress. Explicit гнучкіший під нетипові умови, але має високий ризик «забути очікування»; auto-wait знімає рутину, але нетипові умови доводиться дописувати вручну. Є ще третій, історичний механізм — неявне очікування (implicit wait) у Selenium: глобальний таймаут, протягом якого драйвер повторює пошук елемента. Воно вузьке (реагує лише на «елемент не знайдено», не вміє чекати видимість чи клікабельність), а змішування неявного і явного очікувань дає непередбачувані сумарні таймаути — тому рекомендація: обрати щось одне, на практиці явне.

Які перевірки Playwright виконує перед кліком у рамках auto-wait?

Пʼять перевірок актуальності (actionability). Attached — елемент є в DOM. Visible — має непорожній bounding box і не visibility:hidden (при цьому елемент з opacity:0 вважається видимим — типова пастка). Stable — bounding box не змінюється щонайменше два послідовні кадри анімації, тобто елемент не «їде». Receives events — елемент є верхнім у точці дії (hit-test), його не перекриває оверлей. Enabled — немає атрибута disabled. Для дій уведення на кшталт fill додається ще Editable — елемент не readonly. Поки якась умова не виконана, Playwright повторює спроби до таймауту, а потім падає з конкретною причиною — це і робить падіння діагностованим.

Кнопка є в DOM, видима й активна, але клік «нічого не робить». Які можливі причини?

Найімовірніша причина — JavaScript ще не привʼязав обробник події до елемента. Так буває при гідратації (hydration) у React/Vue/Svelte: сервер віддає готовий HTML, а інтерактивність «оживає» лише після завантаження й виконання клієнтського бандлу. Важлива чесність: авто-очікування тут не рятує — Playwright перевіряє, що елемент прикріплений, видимий, стабільний і приймає події, але фізично не може дізнатися, чи навішений onClick у коді застосунку; для браузера кнопка вже «клікабельна». Правильний підхід — чекати на прикладний сигнал готовності: зникнення спінера або атрибут-маркер типу data-hydrated="true", який застосунок сам виставляє. Такий маркер — не стандарт, а домовленість із розробниками, і сильний кандидат саме це й підкреслює: узгодьте з командою, який сигнал означає «інтерактивно готово», і чекайте саме його.

Тест сабмітить форму через AJAX і одразу перевіряє повідомлення про успіх — іноді падає. Як зробити правильно?

Проблема в тому, що перевірка виконується, поки запит ще в дорозі. Частково рятують web-first-твердження на кшталт toBeVisible — вони повторно опитують умову до таймауту. Але надійніше синхронізуватися з подією, на яку реально чекаєш: або через page.waitForResponse на конкретний URL і статус, або через видимий наслідок у UI. Критична деталь із waitForResponse: проміс треба створити до кліку, інакше між кліком і підпискою є вікно, в яке швидка відповідь може прослизнути непоміченою — і це знову гонка. Загальне правило вибору: перевіряй те, що бачить користувач (UI-наслідок), а на мережеву відповідь синхронізуйся тоді, коли зміна в UI непомітна або надто «тонка»; іноді доречно поєднати — дочекатися відповіді, щоб зняти гонку, і окремо стверджувати результат в інтерфейсі.

Тест падає з помилкою «element intercepts pointer events». Що сталося і що робити? Чому force: true — погана ідея?

Це означає, що поверх цільового елемента лежить інший — модалка, напівпрозорий оверлей, тултіп, «липкий» хедер чи cookie-банер. Браузер відправляє клік у точку екрана, і подію ловить верхній за z-порядком елемент, тому Playwright робить hit-test і чесно падає, коли ціль не верхня. Це корисне падіння: тест зловив або реальну проблему UX, або власну помилку. Реакція залежить від причини: модалка ще не закрилась — дочекатися waitFor зі станом hidden; cookie-банер — закрити в передумові, а не «пробивати»; тултіп — прибрати фокус; анімація — дочекатися стабільності. force: true вимикає неосновні перевірки актуальності (зокрема hit-test) й імітує клік попри перекриття — тобто робить тест зеленим, приховавши дефект. Він доречний лише у виняткових випадках, коли ти свідомо тестуєш поведінку під оверлеєм; загальний тест на здоровий глузд — чи зміг би сюди клікнути живий користувач.

Як анімації ламають тести і як їх приборкати?

Анімації псують дві речі. Перше — клік: елемент їде, і координати змінюються між наведенням і натисканням; Playwright тут вимагає стабільності (bounding box незмінний два послідовні кадри) і перечікує, поки елемент рухається. Друге — скріншоти: візуальне порівняння ловить проміжний кадр анімації, і дифф червоніє щоразу по-різному. Найнадійніше — глушити анімації на час тесту: CSS-інʼєкцією виставити нульові animation-duration і transition-duration, або для скріншотів використати вбудовану опцію toHaveScreenshot зі значенням animations: 'disabled' (воно ж дефолтне): скінченні анімації промотуються до кінцевого стану, нескінченні скидаються до початкового. Нюанс для глибини: цей механізм зупиняє CSS-анімації, переходи й Web Animations API, але не чіпає анімації, намальовані вручну через requestAnimationFrame чи на <canvas> — ті доводиться глушити на рівні самого застосунку.

Після логіну йде ланцюжок редіректів із проміжною сторінкою «Зачекайте…». Як тестувати такий флоу?

Головне правило: не привʼязуйся до проміжних URL і не роби припущень про кількість «стрибків» — чекай саме на фінальний стан через page.waitForURL('**/dashboard'), а потім стверджуй видимий елемент дашборда. Тест, який одразу після кліку перевіряє URL, ловить проміжний стан і падає. Варто знати й коди редіректів, бо вони визначають поведінку браузера: 301/302 історично часто змінюють метод на GET, 303 — завжди GET, а 307 і 308 зберігають метод (POST лишається POST). Ще одна тонкість — стани завантаження: domcontentloaded настає, коли розібрано HTML (підресурси й дані ще можуть вантажитися), load — коли завантажено й підресурси; якщо синхронізуватися на domcontentloaded проміжної сторінки, вона за мить зникне разом із твоїм локатором. Тому надійніше чекати кінцевий видимий елемент, а не абстрактне «сторінка завантажилась».

Тести ходять у реальний платіжний шлюз і періодично червоніють без змін у коді. Що робити?

Тест, який реально бʼється об сторонній сервіс, успадковує всю його нестабільність: таймаути, ліміти запитів, зміни у відповідях, падіння в неробочі години — він червоніє не тому, що зламався твій застосунок. Рішення — розділити наміри. Якщо перевіряєш свою логіку, зовнішній сервіс ізолюй через мок або стаб на рівні мережі: у Playwright це page.route з route.fulfill, який віддає детерміновану відповідь; аналог у Cypress — cy.intercept. Бонус мокання — легко перевірити крайні випадки: помилку 500, порожню чи повільну відповідь. Окремо варто мати контрактні або end-to-end тести, які таки ходять у реальний сервіс, але їх виносять в окрему повільну категорію, ганяють рідше й не блокують ними основний пайплайн. Змішувати одне з іншим — прямий шлях до «червоного, якому ніхто не вірить».

Що таке протікання стану між тестами і як забезпечити ізоляцію?

Протікання стану (state leakage) — це коли один тест лишає по собі слід, а інший на нього спотикається: тест A створює користувача test@x.com, тест B намагається створити такого самого й падає на «вже існує», або тести працюють лише в певному порядку. Стан протікає через базу даних, localStorage/cookies/сесію, кеш, зовнішні черги й глобальні змінні тест-фреймворку. Принципи ізоляції: свіжий контекст на тест (у Playwright кожен тест за замовчуванням отримує чистий browser context — окремі cookies і storage); унікальні дані замість хардкоду — генеруй email через timestamp плюс UUID на кожен запуск; кожен тест сам створює свої передумови й прибирає за собою, не спираючись на «спадок» попереднього. Важлива деталь про teardown: прибирання роби в afterEach або фікстурі, а не наприкінці «щасливого» шляху — при падінні тест до прибирання просто не дійде. На спільному стенді стратегію очищення узгоджуй окремо, бо можна зачепити чужі дані.

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

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

Навіщо навмисно уповільнювати мережу в тестах?

Щоб витягнути назовні гонки (race conditions) — найпідступніші баги, які на швидкій мережі сплять, бо порядок подій «випадково правильний». Тротлінг розтягує запити в часі й оголює подвійні сабміти, роботу з ще незавантаженими даними, «спінер завис назавжди». Технічно є два шляхи. Перший — Network.emulateNetworkConditions через CDP-сесію: задаєш пропускну здатність у байтах за секунду і затримку в мілісекундах; це команда Chrome DevTools Protocol, тому працює лише в Chromium. Другий, простіший і кросбраузерний — штучна затримка конкретного запиту через page.route: затримати відповідь /api/cart на дві секунди й перевірити, чи блокує застосунок повторне натискання «Оформити», поки перший запит «висить». Так тест з інструмента підтвердження перетворюється на інструмент пошуку реальних race-багів.

Тест стабільно зелений локально, але флакне на CI. Які найтиповіші причини і як їх ловити?

Локальна машина й CI — різні світи, і причини варто перебирати системно. Перша — ресурси: CI-раннер слабший і завантаженіший, те, що локально стається за 200 мс, там займає 2 с, і жорсткі таймаути не витримують; лікування — розумні очікування, адекватні таймаути, менше воркерів. Друга — headless проти headed і розмір вікна: CI гонить headless із дефолтним, часто меншим viewport, і елемент опиняється за межами видимої області або зʼїжджає в мобільний лейаут; лікування — фіксувати viewport у конфізі й ганяти локально в тому самому режимі. Третя — часовий пояс і локаль: CI нерідко в UTC та англійській локалі, і тест, що звіряє відформатовану дату чи текст, ламається; лікування — фіксувати TZ, локаль, Accept-Language, не покладатися на «сьогоднішню» дату без мокання часу. Інші винуватці: гонки при паралелі, відсутні системні шрифти, різні версії браузера. Практичний прийом, який відрізняє сеньйора: відтворити умови CI локально — той самий Docker-образ, headless, той самий viewport, TZ=UTC, обмежені CPU; флак, який «не ловиться локально», майже завжди ловиться, щойно середовище зробити схожим на CI.

Тест червоний. Як визначити, хто винен — застосунок, тест чи середовище?

Є дисциплінований алгоритм замість гадань. Спершу прочитай помилку буквально — тип помилки вже звужує коло: «intercepts pointer events» — щось перекриває клік, таймаут селектора — елемент не зʼявився, «expected 200, got 500» — впав бекенд. Далі подивись артефакти: скріншот, відео, trace, логи мережі й консолі на момент падіння. Потім відтвори локально в умовах CI (той самий образ, headless, viewport, TZ) — якщо локально стабільно зелено, а на CI червоно, підозра зміщується на середовище. Прожени тест 20–50 разів: стабільно червоний — детермінований баг, іноді червоний — флак. Ізолюй: наодинці зелений, у наборі червоний — протікання стану чи конкуренція за паралель. Симптоми мапляться на винуватців: падає лише в паралелі — тест (ізоляція); лише на CI — середовище; стабільно скрізь після зміни коду — застосунок; раз на N без системи — гонка плюс слабке очікування. І головне для сеньйорської відповіді: якщо винен застосунок, тест має лишатися червоним і фіксувати регресію, а не «зеленитися» через force чи sleep; а поки причина не відтворена й не виміряна, чесне формулювання — «ще не встановлено», а не поспішний root cause.

Три кейси, де тест і застосунок живуть у різному часі: гонка навколо AJAX-сабміту (і чому проміс відповіді створюють до кліку), перекритий клік, який force: true тихо ховає замість лагодити, і навмисне вповільнення мережі, що перетворює тест з інструмента підтвердження на інструмент пошуку race-багів. Скрізь — що дивитися і чому.

Кейс 1. AJAX-сабміт: синхронізуйся з подією, а не з надією

Тест заповнює форму, тисне «Надіслати» й одразу перевіряє «Готово». Запит ще в дорозі — і перевірка ловить стару сторінку. Наївний варіант флакне саме на швидкій відповіді, коли встигає прослизнути повз:

await page.getByLabel('Email').fill('a@b.com');
await page.getByRole('button', { name: 'Submit' }).click();
// Погано: перевіряємо до того, як прийшла відповідь
await expect(page.getByText('Готово')).toBeVisible();

Надійніше синхронізуватися з тією самою подією, на яку ти чекаєш. Проміс відповіді створюють до кліку — інакше між кліком і викликом waitForResponse лишається вікно, крізь яке швидка відповідь проскочить непоміченою:

// Знімаємо гонку: проміс відповіді існує ще до кліку
const respPromise = page.waitForResponse(
  (r) => r.url().includes('/api/subscribe') && r.status() === 200
);
await page.getByRole('button', { name: 'Submit' }).click();
await respPromise;
await expect(page.getByRole('alert')).toHaveText('Готово');

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

• Порядок рядків тут — не косметика. Створиш waitForResponse після кліку — і на швидкому бекенді відповідь приходить раніше, ніж ти почав слухати. Тест зелений «здебільшого», а червоніє рівно тоді, коли сервер відповів найшвидше. Проміс має жити раніше за дію, що його спричиняє.
• toBeVisible/toHaveText самі перечікують. Web-first-твердження опитують умову до таймауту, тож голий expect без waitForResponse теж інколи виживає. Але це маскування гонки живучістю асерту, а не її усунення — на межі таймауту воно все одно впаде.
• Перевіряй те, що бачить користувач. За замовчуванням стверджуй UI-наслідок (alert з текстом), а на мережеву відповідь синхронізуйся, коли зміна в UI надто «тонка», щоб надійно за неї зачепитися. Іноді доречно поєднати: дочекатися відповіді, щоб зняти гонку, і окремо перевірити результат в інтерфейсі.

Кейс 2. Перекритий клік: force: true не лагодить, а ховає баг

Елемент є, видимий, обробник навішений — а клік летить «повз», бо поверх лежить оверлей, модалка, тултіп чи cookie-банер. Playwright робить hit-test («отримує події»): перевіряє, що цільовий елемент — верхній у точці кліку. Якщо ні — повторює спроби й падає з підказкою про перехоплювача:

<div class="overlay">…</div> intercepts pointer events

Спокуса — «пробити» перешкоду силовим кліком. Це найгірша реакція:

// Погано: обходимо перевірки й ховаємо реальний баг
await page.locator('#save').click({ force: true });

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

// Дочекатися, поки перекривач зникне, і клікати чесно
await page.locator('.overlay').waitFor({ state: 'hidden' });
await page.locator('#save').click();

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

• force: true вимикає перевірки актуальності, зокрема hit-test. Тест зеленіє, імітуючи клік попри перекриття, а дефект UX (банер, що не закрився; модалка-привид) лишається в проді. Питання-фільтр: а живий користувач узагалі зміг би сюди клікнути?
• Читай перехоплювача з повідомлення буквально. intercepts pointer events називає елемент, який зловив клік. Cookie-банер чи оверлей закривають у передумові, залишок модалки перечікують через waitFor({ state: 'hidden' }), тултіп прибирають зняттям фокуса, анімацію — очікуванням стабільності.
• Це корисне падіння, а не завада. Тест зловив або реальну проблему інтерфейсу, або власну відсутність очікування. force доречний лише як свідомий виняток (наприклад, навмисно тестуєш поведінку під оверлеєм), не як спосіб озеленити червоне.

Кейс 3. Тротлінг мережі: витягуємо race-баг подвійного сабміту

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

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

test('повторний «Оформити» під час висячого запиту не створює другий order', async ({ page }) => {
  let orderPosts = 0;
  await page.route('**/api/checkout', async (route) => {
    orderPosts += 1;
    await new Promise((r) => setTimeout(r, 2000)); // тримаємо запит «у дорозі»
    await route.continue();
  });

  await page.goto('https://shop.example.com/cart');
  const submit = page.getByRole('button', { name: 'Оформити' });

  await submit.click();
  // друге натискання в обхід auto-wait: звичайний click() чекатиме enabled
  // і не відтворить гонку, коли застосунок уже вимикає кнопку
  await submit.dispatchEvent('click');

  await expect(submit).toBeDisabled(); // застосунок мусив заблокувати кнопку
  expect(orderPosts, 'подвійний сабміт створив два замовлення').toBe(1);
});

У Chromium той самий ефект дає емуляція умов мережі через протокол DevTools (CDP):

// Лише Chromium: Network.emulateNetworkConditions — команда CDP
const client = await context.newCDPSession(page);
await client.send('Network.emulateNetworkConditions', {
  offline: false,
  downloadThroughput: (200 * 1024) / 8, // байти/с ≈ 200 кбіт/с
  uploadThroughput: (200 * 1024) / 8,
  latency: 400, // мс затримки на запит
});

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

• Затримка через route — точковий скальпель. Ти гальмуєш саме той запит, у якому підозрюєш гонку, і встигаєш натиснути кнопку двічі, поки перший виклик висить. Лічильник orderPosts перетворює невидиму гонку на вимірюваний факт: якщо кнопка не блокується, до бекенду піде два POST.
• emulateNetworkConditions — тільки Chromium. Це команда CDP, тож для WebKit і Firefox через Playwright такого важеля немає; downloadThroughput/uploadThroughput задають у байтах за секунду (-1 вимикає тротлінг), latency — у мілісекундах. Коли треба кросбраузерно — бери затримку через page.route.
• Це не hard sleep. setTimeout тут стоїть усередині обробника запиту — він моделює повільну мережу, а не «спить наосліп» у тілі тесту замість очікування умови. Сам тест синхронізується з реальним станом кнопки (toBeDisabled) і з лічильником запитів, а не з годинником.

Флак і природа синхронізації

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

Очікування: auto-wait, explicit wait, hard sleep

• Можу пояснити різницю між авто-очікуванням (Playwright перевіряє актуальність перед дією) і явним очікуванням (WebDriverWait у Selenium, умову й таймаут пишу сам).
• Знаю п'ять перевірок актуальності Playwright перед кліком: Attached, Visible, Stable, Receives events, Enabled (і Editable для введення).
• Можу пояснити, чому hard sleep (sleep(3)) погано: він синхронізується з годинником, а не з застосунком — і мало на CI, і забагато локально.
• Розумію, чому неявне очікування (implicit wait) у Selenium небезпечно змішувати з явним: непередбачувані сумарні таймаути; обирай щось одне.
• Знаю, що авто-очікування не всесильне: воно не бачить прикладних станів (навішений обробник, завершений AJAX).

Типові сценарії гонок

• Можу пояснити, чому елемент є в DOM, видимий і активний, але клік «нічого не робить» — не навісився обробник під час гідратації (hydration); рятує лише прикладний сигнал готовності.
• Знаю, чому проміс waitForResponse створюють ДО кліку, а не після — інакше швидка відповідь прослизне повз.
• Розумію правило AJAX-сабміту: перевіряй UI-наслідок, який бачить користувач, а на мережеву відповідь синхронізуйся, коли зміна в UI надто тонка.
• Можу пояснити hit-test («receives events»): клік ловить верхній за z-порядком елемент, тож модалку/оверлей/банер треба дочекатися або закрити в передумові, а не бити force: true.
• Знаю, чому не варто прив'язуватися до проміжних URL при редіректі, а чекати фінальний стан (waitForURL); розумію різницю кодів 301/302/303 vs 307/308 щодо збереження методу.

Ізоляція, середовище й діагностика

• Можу пояснити, чому тест зелений локально, але флакне на CI: ресурси й швидкість, headless/viewport, TZ/локаль і дані середовища.
• Розумію протікання стану (state leakage) і принципи ізоляції: свіжий контекст на тест, унікальні дані, власні передумови, teardown в afterEach.
• Знаю, чому падає паралельний прогін: конкуренція за спільні дані, глобальні перемикачі, обмежені ресурси, порядок як прихована залежність.
• Можу пояснити, навіщо мокати нестабільний зовнішній API (page.route/cy.intercept) і виносити реальні контрактні тести в окрему повільну категорію.
• Знаю, як тротлінгом мережі (CDP Network.emulateNetworkConditions або затримка в route) навмисно оголити race-баги на кшталт подвійного сабміту.
• Можу провести алгоритм діагностики «застосунок / тест / середовище»: прочитати помилку буквально, глянути артефакти, відтворити умови CI, прогнати багато разів, ізолювати запуск — і чесно сказати «ще не встановлено», поки причина не виміряна.