🎲 Російська рулетка в CI/CD: Чому retries: 3 у ваших автотестах — це посадовий злочинПривіт, екіпаж! Зізнавайтесь, у вас бувало таке? Ви зливаєте гілку, пайплайн червоніє, якийсь E2E тест падає з помилкою. Ви закочуєте очі, натискаєте кнопку "Rebuild", йдете за кавою, повертаєтесь — о диво, пайплайн зелений! Код летить на продакшен. ☕️Щоб не натискати "Rebuild" руками, команди знаходять "геніальне" рішення. Вони відкривають конфіг Cypress чи Playwright і додають один магічний рядок: retries: 3. Менеджмент щасливий, нестабільні (flaky) тести більше не блокують релізи.Але правда в тому, що ви щойно засунули архітектурну бомбу у свій продукт. Автоматичні ретраї — це не вирішення проблеми, це спроба заклеїти тріщину у фундаменті скотчем.Ось чому ваші "самолікувальні" пайплайни насправді руйнують проєкт:🏎 Приховування Race Conditions (Перегони даних)Тест падає не тому, що "інтернет кліпнув" або "хмара затупила". У 90% випадків він падає, бо ваш фронтенд іноді рендерить компонент швидше, ніж бекенд (який зараз під навантаженням) встигає віддати дані.Натискаючи Retry, ви просто ховаєте реальний race condition. На продакшені у юзера з повільним 3G інтернетом ніякого ретраю не буде — він просто отримає білий екран замість кошика. ⏳ Інфляція часу (CI Timeout Hell)Ви починаєте з малого, але flaky-тести розмножуються як віруси. Якщо у вас 100 тестів, і 10 з них нестабільні, кожен намагатиметься пройти по 3 рази, збираючи таймаути. Ваш швидкий пайплайн, який мав летіти за 5 хвилин, перетворюється на 40-хвилинного монстра. Розробники починають ненавидіти AQA-відділ, бо змушені чекати годину, щоб залити зміну в один рядок CSS. 🪟Ефект Зламаного Вікна (Втрата довіри)Як тільки команда звикає, що пайплайн іноді червоний "просто так", довіра до автоматизації падає до нуля. Коли впаде реально важливий тест, який знайшов критичну діру в авторизації, розробник навіть не подивиться в логи. Він скаже: "А, це знову той нестабільний тест, я просто перезапущу джобу". Як з цим борються справжні інженери?Жорсткий Карантин (Quarantine). Якщо тест хоча б раз кліпнув і впав без явної причини — його негайно забирають із загального прогону. Він помічається тегом @quarantine, продовжує бігати ізольовано, збираючи логі, але більше не впливає на CI/CD розробників. На автора тесту автоматично заводиться Critical баг. Поки тест у карантині — фіча вважається непокритою.Висновок: Тест має бути як скальпель — або ідеально гострим, або він лежить у смітнику. Якщо ви не можете написати стабільний тест на фічу, краще тестуйте її руками, ніж створюйте ілюзію безпеки через retries.А яка у вас політика щодо ретраїв на проєкті? 👇🔥 — Ніяких поблажок! Впав один раз — розбираємо логи до фундаментальної причини.👀 — У нас стоїть retry: 2, інакше ми б ніколи нічого не релізнули...🤬 — В мене тести падають, бо тестовий енв постійно лежить, ретраї — це мій єдиний порятунок!