Флакі-тести: причини, діагностика, лікування

Що таке флакі-тест?

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

Чому один нестабільний тест — це непропорційно велика проблема?

Бо він руйнує не себе, а довіру до всієї сюїти. Щойно команда переконується, що червоне буває «несправжнім», спрацьовує ефект хлопчика, який кричав «вовки»: кожне падіння списують на флак і ретраять, не читаючи. У цій атмосфері справжня регресія проходить непоміченою — її ховає той самий рефлекс «та це знову моргнуло». Додатково страждає CI-гейт: якщо merge розблоковують ретраєм джоба до першого зеленого, гейт нічого не гарантує, він лише вдає контроль. І це коштує грошей — кожен фальшивий червоний з'їдає чийсь час на розбір звіту, помножений на розмір сюїти й частоту прогонів. Тому флак лікують, а не терплять: один терпимий флакі-тест нормалізує наступний.

Назви сімейства причин флаку.

Ми групуємо джерела флаку в п'ять сімейств, і ця класифікація сама по собі є алгоритмом діагностики. Одразу застереження: це наше перегрупування, а не вичерпний поділ — у xUnit Patterns таксономія Erratic Test інша, у Фаулера п'ятірка своя (з витоком ресурсів, якого в нас немає), а Google перелічує причини відкритим списком із «etc.». Перше — синхронізація: тест і застосунок працюють асинхронно, тест звертається до елемента чи даних раніше, ніж вони готові. Друге — дані: тест залежить від стану, який не контролює повністю (брудні дані з попереднього прогону, неунікальний email, час і випадковість). Третє — порядок і взаємозалежність: тест спирається на стан, який лишив інший тест, тож ламається при зміні порядку чи паралелі. Четверте — оточення й інфраструктура: слабший CI-агент, моргання мережі, повільний сторонній сервіс, headless проти headed. П'яте — баг продукту: застосунок справді недетермінований (реальна гонка, кінцева узгодженість). Сильна відповідь — це п'ять сімейств із прикладом на кожне, а не хаотичний перелік «мережа, таймінги, ще щось».

Що таке hard wait і чому це антипатерн?

Жорстке очікування (hard wait) — це пауза на фіксовану кількість мілісекунд у надії, що «стільки точно вистачить», наприклад page.waitForTimeout(2000) перед асертом. Проблема в тому, що фіксована пауза програє в обидва боки: на швидкому прогоні вона просто гальмує сюїту без користі, а на повільному, навантаженому агенті — не дочікується потрібного стану й падає. Вона прив'язана до часу, а не до події, тоді як момент готовності UI плаває на десятки й сотні мілісекунд. Правильний інструмент — очікування за умовою: web-first assertion з автоочікуванням, полінг стану, очікування конкретної відповіді мережі. Такий асерт сам чекає появи елемента до свого таймауту й закривається щойно умова виконана, тому він одночасно швидший і стабільніший за будь-яку фіксовану цифру.

Як тести флакають через дані?

Тест залежить від стану, який він не створив і не контролює до кінця. Типові прояви: два тести одночасно правлять одного й того ж користувача; дані з попереднього прогону не прибрані й ламають передумову; тест створює запис із фіксованим email і на повторі падає на дублікаті; перевірка спирається на «перший рядок таблиці», хоча порядок недетермінований. Окрема підступна гілка — час, дати й випадковість: тест, що падає лише опівночі чи в чужій таймзоні, перевірка «створено сьогодні» на межі доби, Math.random() у тестових даних. Лікується це ізоляцією й детермінізмом: унікальні дані на кожен тест, підготовка стану через API чи БД замість UI, фіксація часу й сідів генератора. Головний принцип — тест сам володіє своїми даними й не покладається на те, що лишили сусіди.

Тест зелений, коли йде п'ятим, і червоний, коли перший. Про що це?

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

Тест зелений локально, червоний у CI. Твої дії?

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

Флак через оточення — які джерела й головний важіль лікування?

Тут тест падає не через свій код, а через середовище виконання. Джерела: перевантажений CI-агент дає інші таймінги; моргання мережі; недоступний або повільний сторонній сервіс — платіжка, пошта, зовнішнє API; різниця headless проти headed; відсутні шрифти в Docker ламають скріншотні тести; чужа таймзона чи локаль агента; застаріла версія фронтенду з CDN або service worker. Головний важіль — прибрати з-під ніг тесту зовнішні залежності, які нестабільні й не є об'єктом перевірки: підмінити їх дублером (стаб/мок). Якщо мета тесту не в самому платіжному провайдері, його моргання не повинно фарбувати твій тест у червоне. Це не «читерство», а елементарна ізоляція: тест має перевіряти свою поведінку, а не аптайм чужого сервісу.

Чи завжди флак — це провина тесту?

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

Як діагностувати флак?

Діагностика відповідає на два питання: чи це взагалі флак (а не стабільно відтворюваний баг) і до якого з п'яти сімейств він належить. Спершу — артефакти: флак рідкісний і його майже неможливо зловити «дивлячись очима», тому інфраструктура має ловити його за тебе — трейс (trace) з покроковими знімками DOM, мережею й консоллю, відео падіння, скріншот моменту збою, серверні логи з correlation id. Без збережених артефактів флак недіагностовний, бо на повторному прогоні він уже зелений. Далі — керований повтор: ганяєш тест сотнями ітерацій у циклі (--repeat-each у Playwright або скрипт-обгортка в іншому ранері), бажано під навантаженням, що імітує CI. Якщо в ізоляції тест стабільний, а в повному наборі — ні, ти щойно локалізував причину як «порядок і взаємозалежність».

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

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

Ретраї — це добре чи погано?

Це залежить від того, чим ретрай (retry) супроводжується, і питання перевіряє зрілість. Ретрай легітимний як тимчасове знеболювальне для справді неусувних рідкісних збоїв інфраструктури — наприклад, моргання мережі до стороннього сервісу, який ти не контролюєш, — поки команда рухається до кореневого фіксу. Але за однієї умови: ретрай не мовчить. Кожен «passed on retry» логується як сигнал флаку, потрапляє в метрику й у беклог на розбір. Ретрай стає маскуванням, коли retries виставляють глобально й високо, щоб сюїта «просто була зеленою», і на цьому заспокоюються: справжня гонка продукту ховається за зеленим, час прогону росте, а стимул чинити флак зникає. Правило коротке: ретрай купує час, але не скасовує обов'язку знайти причину. Тест, що стабільно проходить лише з другої спроби, — не «майже зелений», а незафіксований дефект.

Що таке карантин і як зробити його правильно?

Карантин (quarantine) — це відповідь на ситуацію, коли тест флакає прямо зараз і блокує merge всій команді, а причину швидко не знайти. Тест позначають спеціальним тегом (наприклад @flaky), виносять із блокувального гейта, щоб він більше не валив чужі PR, але продовжують ганяти й відстежувати. Карантин розв'язує конфлікт: один флакі-тест не має права зупиняти доставку всієї команди, але й тихо видаляти його не можна — він щось перевіряє. Критично, щоб карантин не став цвинтарем: у правильного карантину є власник, дедлайн і тікет. Тег без відповідального й строку — це просто спосіб назавжди перестати дивитися на тест. Жорсткіший варіант для зовсім занедбаних тестів — видалити тест, а не тримати вічно зеленим через ретраї, бо мертвий тест створює ілюзію покриття, якого немає. Це наша позиція, і вона розходиться з каноном: xUnit Patterns називає прибирання тесту одним із двох шкідливих простих виходів, бо це свідома втрата покриття.

Які метрики стабільності сюїти корисні й чесні?

Флак не лікують наосліп — без цифр «здається, стало краще» ніхто не спростує. Flaky rate — частка тестів чи прогонів, що дали різний результат за фіксованого коду; це найпряміший вимір здоров'я сюїти. Passed on retry — скільки тестів проходять лише з ретраю; прямий детектор прихованого флаку, бо позеленіння після червоного без змін коду означає нестабільність за визначенням. Розмір і вік карантину показують, чи команда виносить тести швидше, ніж чинить: зростаючий тренд — тривожний сигнал. Час до фіксу — скільки живе флакі-тікет від заведення до закриття. Свідомо уникай вигаданих «індустріальних порогів» на кшталт «прийнятно 2%»: конкретна межа залежить від розміру сюїти, зрілості й критичності продукту, тож важливіший напрямок тренду, ніж магічне число.

З чого складається здорова командна політика щодо флаку?

Технічні прийоми не працюють без домовленостей, і політика тримається на кількох рішеннях. Ownership: у кожного червоного є хтось, хто відповідає за розбір, інакше «нічий» флак живе вічно. Флак як дефект, а не фон: нестабільний тест заводиться як баг із пріоритетом, а не «колись подивимось» — бо один терпимий флак нормалізує наступний. Правила гейта: команда домовляється, що саме блокує merge і за яких умов тест іде в карантин, а не тихо ретраїться; сюди ж — розкладка прогонів (smoke на PR, повна регресія nightly). Бюджет на стабільність: свідомо виділений час на прибирання сюїти, бо флак накопичується сам, а розсмоктується — ні. Без цих рамок будь-які web-first assertion і фікстури поступово тонуть у загальному «та ретрай».

Побудуй структуру сильної відповіді про боротьбу з флаком.

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

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

Кейс 1. Симптом → сімейство → перевірка (таблиця рішень)

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

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

Кейс 2. Локалізація керованим повтором

Тест checkout падає в CI приблизно раз на п'ятнадцять прогонів, локально не відтворюється жодного разу. Спокуса — поставити retries і забути. Правильний хід — спершу зрозуміти, до якого сімейства він належить, а для цього потрібен не ручний ретрай, а керований повтор під навантаженням.

Крок перший — зловити артефакт. Trace в Playwright дає покрокові знімки DOM, мережу й консоль саме того прогону, що впав, — без нього флак недіагностовний:

// playwright.config.ts — зберігати трейс лише для падінь, щоб не роздувати артефакти
export default defineConfig({
  use: { trace: 'retain-on-failure' },
});

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

# 200 повторів у 4 воркери — витягує приховані гонки синхронізації
npx playwright test checkout.spec.ts --repeat-each=200 --workers=4

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

# той самий тест ізольовано: стабільний тут = винні сусіди, не він
npx playwright test checkout.spec.ts --repeat-each=200 --workers=1

Що дивитися і чому. Якщо падіння відтворюється вже під --workers=4, а на одному воркері зникає — ти локалізував гонку за спільний ресурс (спільний акаунт, один рядок БД), і фікс лежить у площині ізоляції даних, а не таймаутів. Якщо ж тест плаває навіть у повній ізоляції на слабких ресурсах — дивись трейс на конкретний крок: майже завжди це синхронізація, де hard wait не дочекався повільнішого за звичай рендеру. Головне, чого цей кейс уникає: висновку «це просто крихкий тест» без єдиного відтворення. Причину тут не вгадують, її показує повтор.

Кейс 3. Чесний ретрай і карантин, які не ховають флак

Тест profile-update почав плавати перед релізом, причину за годину не знайшли, а він блокує merge усій команді. Тут доречні ретрай і карантин — але так, щоб вони не стали способом більше ніколи на тест не дивитися.

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

// playwright.config.ts — знеболювальне на час лікування, не заміна фіксу
export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  reporter: [['list'], ['json', { outputFile: 'results.json' }]],
});

Карантин виносить тест із блокувального гейта тегом, але не глушить його: він і далі ганяється й трекається:

test('оновлення профілю зберігає зміни', { tag: '@flaky' }, async ({ page }) => {
  // ... сценарій без змін; тег лише виводить тест із блокувального прогону
});

І найважливіша частина, без якої попередні дві безглузді, — сигнал у метрику. Кожен «passed on retry» треба видобути зі звіту й підняти як дефект, а не проковтнути:

# скільки тестів позеленіли лише з ретраю — прямий детектор прихованого флаку
jq '[.suites[].specs[].tests[] | select(.results | length > 1)] | length' results.json

Що дивитися і чому. По-перше, retries: 2 тут купує команді час до релізу, але тест уже заведений у беклог із власником і дедлайном — тег @flaky без тікета був би тихим списанням. По-друге, підрахунок passed on retry перетворює флак із відчуття на цифру: якщо число росте, ретраї маскують проблему, а не тримають її під контролем. По-третє, коли причину знайдено й полагоджено, тег знімають і повертають тест у гейт — карантин мусить мати вихід, інакше він цвинтар. Різниця між цим кейсом і «поставив retries: 3 і забув» — рівно в тому, що тут ретрай видимий, вимірюваний і тимчасовий.

Суть і небезпека

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

Таксономія причин

• Назву п'ять сімейств причин напам'ять: синхронізація, дані, порядок і взаємозалежність, оточення, баг продукту.
• Розумію, що ця класифікація сама і є алгоритмом діагностики — кожне сімейство має свій симптом і свій метод лікування.
• Знаю, що наша п'ятірка — педагогічне перегрупування, а не вичерпний поділ: у xUnit Patterns своя таксономія Erratic Test, у Фаулера своя п'ятірка з витоком ресурсів, а Google перелічує причини з «etc.».
• Знаю, що порада «краще видалити занедбаний тест» — наша позиція: xUnit Patterns називає прибирання тесту одним із двох шкідливих виходів, бо це свідома втрата покриття.
• Можу пояснити, чому hard wait (waitForTimeout) програє web-first assertion: він прив'язаний до часу, а не до події готовності.
• Знаю симптом «даних»: неунікальний email, брудний стан із попереднього прогону, залежність від «першого рядка», час і Math.random().
• Розпізнаю залежність від порядку: тест зелений п'ятим і червоний першим означає спільний стан, а не власний баг тесту.
• Знаю типові джерела «оточення»: слабший CI-агент, моргання мережі, повільний сторонній сервіс, headless проти headed, шрифти, таймзона.

Баг продукту vs крихкий тест

• Тримаю в голові обидві тези одночасно: фейл тесту ≠ баг продукту, але й флак ≠ автоматично провина тесту.
• Перш ніж глушити нестабільний тест ретраєм, виключаю справжню гонку в продукті (race condition, eventual consistency).

Діагностика

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

Ретраї, карантин, метрики, політика

• Можу розмежувати легітимний ретрай (тимчасове знеболювальне з логуванням і беклогом) і маскування (глобальні retries, щоб просто позеленіти).
• Розумію правило «ретрай купує час, але не скасовує фіксу»: passed on retry — це незафіксований дефект, а не «майже зелений».
• Знаю, що правильний карантин має власника, дедлайн і тікет, інакше тег @flaky — тихе списання перевірки.
• Можу назвати чесні метрики: flaky rate, passed on retry, розмір і вік карантину, час до фіксу — і чому «магічний поріг» гірший за тренд.
• Розумію складові командної політики: ownership червоного, флак як дефект із пріоритетом, правила гейта, бюджет на стабільність.