Боротьба з флаком засобами інструмента

Що таке флакі-тест і чому «перезапустив — став зелений» не вважається виправленням?

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

Чому «поставити паузу на три секунди» — погана відповідь на нестабільність?

Тому що пауза не повʼязана з тим, чого тест насправді чекає, і програє в обидва боки: коротка не рятує на завантаженому CI-агенті, довга множиться на сотні тестів і перетворює прогін на непідйомний за часом. Документація Selenium називає корінь проблеми прямо — це гонка (race condition) між браузером і кодом тесту: іноді сторінка встигає раніше, іноді тест, а пауза лише зсуває ймовірність, не прибираючи саму гонку. Робочий підхід протилежний: чекати на умову, а не на час — на видимість елемента, на доступність кнопки, на конкретну відповідь мережі. У Playwright цю роль виконують автоочікування і ретрайні асерти, у Selenium — явні очікування з умовою. Жорстка пауза лишається легітимною хіба що як тимчасовий діагностичний зонд під час розслідування, і саме в такому статусі її не мерджать у main.

Ретраї увімкнені за замовчуванням? На яких рівнях їх задають?

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

Тест упав, а на повторі пройшов. Він пройдений?

Ні. Ранер має для цього три статуси, а не два: passed — зелений з першої спроби, flaky — червоний спочатку й зелений на повторі, failed — червоний і на старті, і на кожному з повторів. Тобто результат «зеленіє лише з другого разу» має окрему назву, і сюїта з десятком таких тестів стабільною не є, навіть якщо пайплайн світиться зеленим. Цей сигнал інструмент віддає безкоштовно — питання лише в тому, чи рахує його ваш звіт окремою метрикою. Якщо не рахує, показник стабільності фіктивний: ви вимірюєте не якість тестів, а щедрість налаштування ретраїв. Саме тому категорію flaky варто виносити в дашборд поруч із падіннями, а не ховати у зведеному «зелено».

Які важелі проти флаку дає сам інструмент, а чого він не лікує?

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

Що технічно відбувається під час ретраю і чому це шкодить діагностиці?

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

Чим погана схема «падінням вважаємо лише те, що впало тричі поспіль»?

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

Як перевірити банер «сесія завершиться за 30 хвилин», не чекаючи 30 хвилин?

Підміною часу (clock mocking): тест бере годинник сторінки під контроль і перемотує його вперед. У Playwright це page.clock — встановлюємо потрібний момент, відкриваємо сторінку, викликаємо перемотування на потрібний інтервал і одразу асертимо появу банера. Виграш подвійний, але головний не той, про який думають першим: прискорення прогону — приємний бонус, а суть у тому, що час перестає бути джерелом випадковості. Реальний годинник дає різні результати опівночі, на межі місяця, при переході на літній час і на повільному агенті; підмінений — однакові за будь-яких умов. Відповідь «збільшимо таймаут тесту до 31 хвилини» на співбесіді читається як нерозуміння задачі: вона робить прогін довшим і не прибирає жодної причини нестабільності.

Що саме перевизначає page.clock і чого він не зачепить?

Підміняється не «час узагалі», а перелічений поіменно набір глобальних сутностей сторінки: Date, setTimeout, setInterval, requestAnimationFrame і performance. Під контроль тесту переходить усе, що на них спирається: періодичне опитування сервера, зворотний відлік до кінця акції, дебаунс у полі пошуку, попередження про завершення сесії, анімації на кадрах. І навпаки — усе, що рахує час на бекенді, підміна клієнтського годинника не зачепить: серверний токен протухне за реальним часом, скільки б ви не перемотували сторінку. Сильна відповідь називає цю межу сама, без підказки. Практичний наслідок: сценарії з серверними таймерами тестують іншим способом — керованим станом на боці API або тестовим ендпоінтом.

Коли брати setFixedTime, а коли install із перемотуванням?

Порядок вибору дока задає явно: спершу пробуємо page.clock.setFixedTime(), і лише якщо не підходить — page.clock.install(); режим setSystemTime() лишають для складних випадків. Критерій — не зручність, а поведінка застосунку. Якщо треба лише зафіксувати «сьогодні», щоб форматування дати чи знімок не залежали від дня прогону, а таймери мають цокати як завжди, вистачає фіксованого часу. Якщо ж таймери самі спираються на поточну мітку, застиглий час їх просто зупинить: інтервал ніколи не «дозріє», і тест зависне на порожньому екрані до таймауту. Для цього випадку потрібен установлений годинник, який уміє паузу, перемотування і покрокове просування — тоді ви керуєте не тільки датою, а й перебігом.

Підмінили час, а тест усе одно нестабільний. Що перевірити першим?

Порядок викликів. Установка годинника мусить відбутися перед будь-якою іншою дією, повʼязаною з часом — тобто до переходу на сторінку, а не після нього. Порушення цієї вимоги дає не помилку й не виняток, а невизначену поведінку: частина таймерів сторінки вже стартувала на справжньому годиннику і живе своїм життям, поки решта підмінена. На ревʼю це виглядає як черговий загадковий флак, хоча насправді засіб проти флаку вставлено не в те місце. Практичне правило: page.clock.install() іде першим рядком тесту або всередині фікстури, ще до page.goto(). Другий поширений випадок тієї ж скарги — фіксований час там, де потрібне перемотування: тест не флакає, а стабільно чекає події, яка ніколи не настане.

«Ми вимкнули анімації, і флак зник» — наскільки це коректно?

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

Що таке свіжа фікстура (fresh fixture) і чи є нею приватна схема в базі?

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

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

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

Ми поставили seed генератору даних — тепер дані детерміновані?

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

Де межа корисності згенерованих тестових даних?

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

Що прикладаєте до тікета про нестабільний тест?

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

Тест упав по таймауту. Піднімати таймаут?

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

У вас нестабільний тест, а завтра реліз. Ваші дії?

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

Чи буває, що флак — це чесно спійманий недетермінізм застосунку?

Так, і це найцікавіша категорія. Класика — кінцева узгодженість (eventual consistency): запис уже завершився, але наступне читання може повернути ще стару копію, а через мить та сама операція віддасть свіжу. Документація DynamoDB описує це як штатну поведінку, а не дефект, і показова деталь у тому, що суворе читання там задається прямо в запиті прапорцем ConsistentRead. Тобто потрібну передбачуваність подекуди достатньо ввімкнути, а не вибивати повторними спробами: тест, якому потрібні свіжі дані, просить консистентне читання. Якщо перемикача немає, коректний тест перевіряє умову ретрайним асертом замість фіксованої паузи. А якщо застосунок так поводитися не мав — це взагалі не флак, а дефект продукту, і червоний тест тут працює правильно.

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

Кейс 1. Таймер сесії: від паузи до керованого годинника

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

test('банер сесії (як не треба)', async ({ page }) => {
  test.setTimeout(35 * 60_000);          // проблема 1: прогін на пів години
  await page.goto('/dashboard');
  await page.waitForTimeout(30 * 60_000); // проблема 2: чекаємо реальний час
  await expect(page.getByRole('alert')).toBeVisible();
});

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

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

test('банер сесії зʼявляється через 30 хвилин бездіяльності', async ({ page }) => {
  // ПЕРШИЙ рядок: install мусить випередити будь-який виклик, повʼязаний із часом
  await page.clock.install({ time: new Date('2026-03-10T09:00:00Z') });
  await page.goto('/dashboard');

  // до порогу банера ще нема
  await page.clock.fastForward('29:00');
  await expect(page.getByRole('alert')).toBeHidden();

  // перетинаємо поріг — банер має зʼявитися
  await page.clock.fastForward('01:30');
  await expect(page.getByRole('alert')).toContainText('Сесія завершується');
});

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

• Порядок, а не опції. Якщо install опиниться після page.goto(), таймери, заведені при завантаженні сторінки, встигнуть стартувати на справжньому годиннику. Це не помилка і не виняток — це невизначена поведінка, яка на ревʼю виглядає як «знову флакає». Тому виклик іде першим рядком тесту або всередині фікстури.
• Фіксований час і встановлений годинник вирішують різні задачі. Якщо потрібно лише, щоб «сьогодні» не залежало від дня прогону (форматування дати, вік користувача, знімок екрана), достатньо page.clock.setFixedTime(). Якщо ж застосунок сам рахує інтервали від поточної мітки, застиглий час його зупинить — банер не зʼявиться ніколи, і тест чесно дочекається таймауту.
• Асерт «ще немає» так само важливий, як «уже є». Без нього тест пройде навіть тоді, коли банер висить із першої секунди — а це реальний баг, який інакше проїде в прод.
• Клієнтський годинник не керує сервером. Якщо розлогін вирішує бекенд за строком дії токена, перемотування сторінки на нього не подіє: така частина сценарію тестується через API або керований стан на боці сервера.

Кейс 2. Конфігурація, після якої є що розбирати, і тріаж червоного прогону

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

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 2 : 0,   // локально падіння видно одразу
  use: {
    trace: 'on-first-retry',         // доказ пишеться там, де він потрібен
    screenshot: 'only-on-failure',
  },
  projects: [
    { name: 'core', use: { ...devices['Desktop Chrome'] } },
    {
      name: 'billing-sandbox',       // зовнішня пісочниця: більше повторів, і це рішення задокументоване
      retries: 3,
      use: { ...devices['Desktop Chrome'], baseURL: process.env.SANDBOX_URL },
    },
  ],
});

Далі — сам розбір. Порядок питань важливіший за здогад, тому зручно тримати таблицю тріажу під рукою.

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

• Немає ретраїв — немає трейсів. Звʼязка неочевидна, доки не наступиш: trace: 'on-first-retry' пише артефакт саме під час повтору, тож при retries: 0 тека з артефактами лишиться порожньою. Це не поламаний конфіг, а логічний наслідок.
• trace: 'on' не рятує. Режим «на кожен тест» дока не рекомендує через вартість: час прогону й обсяг артефактів ростуть на тисячі зелених тестів, більшість із яких ніхто не відкриє.
• Ретрай стирає частину доказів. Друга спроба стартує в іншому процесі, тож стан, який і спричинив падіння, до неї не доживає; а трейс при on-first-retry — це запис самого ретраю, не першого падіння. Тому до трейсу в тікеті додають аудиторський слід — логи, які зводяться за часовими мітками.
• Числу ретраїв потрібне пояснення. retries: 3 без коментаря про причину — те саме, що замовчаний дефект; рядок із назвою зовнішньої залежності перетворює магічне число на рішення, яке можна переглянути.

Кейс 3. Сюїта зеленіє наодинці й червоніє в наборі

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

// Було: акаунт піднімається один раз на воркер — і всі тести правлять його разом
export const test = base.extend<{}, { account: Account }>({
  account: [async ({}, use) => {
    const account = await api.createAccount();  // дорого, тому «зекономили»
    await use(account);
    await api.deleteAccount(account.id);
  }, { scope: 'worker' }],
});

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

// Стало: токен спільний, дані — приватні на кожен тест
export const test = base.extend<{ cart: Cart }, { token: string }>({
  token: [async ({}, use) => {
    await use(await api.loginServiceUser());   // дороге й незмінне
  }, { scope: 'worker' }],

  cart: async ({ token }, use) => {
    faker.seed(20260730);                      // відтворюваний прогін
    const cart = await api.createCart(token, {
      email: faker.internet.email(),           // на гілку виконання не впливає
      currency: 'UAH',                         // впливає — задано явно
      itemsCount: 0,                           // межа з тест-дизайну, теж явно
    });
    await use(cart);
    await api.deleteCart(token, cart.id);      // прибирання свого, а не чужого
  },
});

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

• Приватна схема в базі проблему не закриває. Вона розводить тести в межах одного прогону, але наступний прогін отримає ту саму базу з наслідками попереднього. Упізнаваний відбиток — тест проходить один раз, а далі стабільно падає на конфлікті унікальності.
• Зерно фіксує послідовність, але не назавжди. Свіжий реліз бібліотеки здатен видати на тому ж зерні інші значення, тож асерти на конкретне згенероване імʼя — міна сповільненої дії. І окремо: там, де дати рахуються від «зараз», відтворюваності немає взагалі, доки під ними немає фіксованої опорної дати.
• Явне важливіше за випадкове там, де є гілка виконання. Валюта, тариф, знижка, вік визначають, яким шляхом піде застосунок, тому їх задають руками. Генерувати корисно те, що потрібне лише для унікальності — пошту, назву, зовнішній ідентифікатор.
• Прибирання не заміняє свіжий стан. Про нього забувають при ранньому виході з тесту, а частину слідів прибрати неможливо в принципі. Якщо вибір стоїть між «акуратно прибираємо спільне» і «створюємо своє», друге стабільніше навіть коштом секунд.

Межа інструмента: причина проти симптому

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

Ретраї: рівні, категорії, ціна

• Знаю, що ретраї вимкнені за замовчуванням, і можу перелічити рівні задання: глобально в конфізі, на файл, на групу, на проєкт (project) — а проєкт це не «ще один браузер», а логічна група з власним таймаутом, середовищем і ретраями.
• Розводжу три категорії результату — passed, flaky, failed — і розумію, що «зелений з другої спроби» пройденим не рахується; якщо звіт не рахує flaky окремо, метрика стабільності фіктивна.
• Памʼятаю, що ретрай іде в новому воркер-процесі: накопичений стан не переїжджає, тож разом із ним зникає і причина падіння, і частина доказів; testInfo.retry дозволяє підготуватися до повтору, але це прийом, а не заміна розслідуванню.
• Можу пояснити ціну схеми «падінням вважаємо лише те, що впало тричі поспіль» словами самого Google: вона знижує хибні спрацювання, але заохочує ігнорувати власний флак, а справжня поломка в 15-хвилинному тесті проявляється аж через три чверті години.
• Маю готову відповідь на «що робити з флакі-тестом»: полагодити, карантин із заведеним багом або свідоме видалення — а не підняти число ретраїв.

Підміна часу і анімації

• Можу пояснити, навіщо page.clock, не зводячи все до швидкості (головне — прибрати час як джерело мінливості), і назвати поіменно, що перевизначається: Date, setTimeout, setInterval, requestAnimationFrame, performance — а також межу: серверні таймери цим не керуються.
• Тримаю в голові порядок вибору режиму — спершу setFixedTime, потім install з паузою й перемотуванням, setSystemTime для складних випадків — і критерій: якщо таймери самі спираються на поточну мітку часу, застиглий годинник їх зупинить.
• Памʼятаю вимогу порядку: install викликається раніше за будь-що інше, що торкається часу, інакше поведінка стає невизначеною — і це виглядає як черговий флак, а не як помилка.
• Не переношу тезу «вимкнули анімації» на всі тести: це дефолт саме асерта-знімка (скінченну ранер прокручує до кінця, нескінченну відкочує на початок, каретку ховає), а для звичайних дій працює перевірка стабільності — незмінна рамка елемента щонайменше протягом двох послідовних кадрів.

Стан, фікстури й тестові дані

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

Докази: трейс, логи, таймаути

• Знаю, чому при падінні в CI дока ставить трейс вище за відео та скріншоти: кадр показує лише результат, а трейс — увесь перебіг (локатори й тривалості дій, стан DOM до і після, мережа, консоль, метадані оточення).
• Памʼятаю канонічну політику запису — трейс на першому повторі впалого тесту, режим «на кожен тест» не рекомендований через вартість — і звʼязку, що при нульових ретраях трейсів не буде взагалі.
• Можу сформулювати вимогу ISTQB до доказів: аудиторський слід із логів фреймворку, застосунку, збірки й деплою, який зводиться за часовими мітками; один скріншот цій вимозі не відповідає.
• Не лікую флак таймаутами: рівні незалежні, тому вичерпаний таймаут асерту не рятується таймаутом тесту, а дока прямо застерігає, що для нестабільного тесту рішення шукати не тут.