Курс Технический менеджер продуктов · автор Stanislav Belyaev
EN RU

Нестабильность тестов (Flakiness)

8 исходящих · 2 входящих · 10 всего связей

Карта Детали
МАСШТАБ КОМАНДЫ
Testing & Quality УСИЛЕНО В МОНОРЕПО

Нестабильность тестов (Flakiness)

Flaky-тесты — это тесты, которые падают недетерминированно, то есть без реальных изменений в коде. Они подрывают доверие к тестовому набору, заставляют разработчиков перезапускать пайплайны и игнорировать реальные падения. Даже 1-2% flaky-тестов могут существенно замедлить весь процесс разработки и деплоя.

Доля тестов с недетерминированным результатом. Google: 16% тестов склонны к флакам.

КОНТЕКСТ МОНОРЕПО

УСИЛИВАЕТСЯ: В монорепах изменения затрагивают больше зависимых проектов, запуская больше тестов. Шанс наткнуться на чужой флаки-тест растёт экспоненциально, что подрывает доверие к CI и парализует работу очереди на мерж.

КОНТЕКСТ РАСПРЕДЕЛЁННЫХ КОМАНД

Косвенное усиление: исправление флака в распределённой команде занимает сутки вместо минут, так как разработчик не может мгновенно перезапустить тест или уточнить причину падения у автора.

Влияние масштаба
👤 Один / Пара (1–3)
0.2
👥 Команда (4–15)
0.4
🏢 Отдел (15–100)
0.8
🏛️ Организация (100+)
1

Нестабильные тесты масштабируются экспоненциально.

8
Влияет на
2
Зависит от

→ Влияет на

Высокий КритическийМОНО
Размер PR

Разработчики группируют изменения в крупные PR, чтобы реже сталкиваться с нестабильными тестами.

Google: 2-16% вычислительных ресурсов уходит на перезапуски из-за flaky тестов
Google Research - Continuous Integration Testing
Монорепо: В монорепозиториях нестабильный тест в ЛЮБОМ потребителе общей библиотеки блокирует весь PR — это многократно усиливает стимул к батчингу изменений.
Высокий КритическийМОНО
Скорость пайплайна (CI/CD)

Перезапуски занимают ресурсы пайплайна, умножая время CI в 2–3 раза.

Slack: 20% стабильности основной ветки
Google + industrial case study (Leinen et al. 2023)
Монорепо: Широкий граф зависимостей означает больше тестов на каждое изменение, что экспоненциально увеличивает вероятность встретить flaky тест.
Очередь на мердж

Один упавший нестабильный тест сбрасывает все PR в очереди каскадом.

10%+ flakiness делает очередь непригодной для использования
GitHub Merge Queue Documentation & Trunk.io
Монорепо: Expedia: 20+ PR конкурируют одновременно — нестабильный тест в любом затронутом проекте сбрасывает всю очередь целиком.
Высокий КритическийМОНО
Время доставки (Lead Time)

Перезапуски + крупные PR + задержки в очереди накапливаются на всех этапах пайплайна.

Влияет на 3+ стадии доставки
Katalon + Gradle research
Удовлетворённость разработчиков

Ложные падения создают фрустрацию и подрывают доверие к CI.

Google: 16% flaky тестов, 84% ложных срабатываний; Atlassian: 21% падений в master из-за flaky тестов
Mozilla Foundation - Understanding Flaky Tests Research
Частота инцидентов

Подорванное доверие → игнорирование падений → баги доходят до прода.

84% падений после коммита — ложные срабатывания
Google Testing Blog - Flaky Tests at Google
Покрытие тестами

Команды отключают нестабильные тесты, создавая постоянные пробелы в покрытии.

Распространено в крупных кодовых базах
Gradle + Atlassian research
PR в неделю

Каждый flaky сбой требует перезапуска. При 16% flakiness (Google) большинство PR ловят хотя бы один flake.

Google: 84% pass→fail это flaky
Google flaky test analysis
Монорепо: Более широкие графы зависимостей в монорепо означают больше тестов на PR = больше подверженность flake. Экспоненциально влияет на throughput.
Распределённые: Flaky сбои за ночь создают 12-24h задержки вместо немедленных перезапусков. Драматически усиливает эффект.

← Зависит от

Средний ВысокийМОНО
Время выполнения тестов

Большие тесты: 14% flaky vs маленькие: 0.5%.

Данные Google
Google Testing Blog (April 2017)
Монорепо: Определение затронутых проектов в монорепо может подтянуть большие интеграционные тесты из других команд, усиливая вероятность встретить flaky тест.
Определение затронутых проектов

Меньше тестов запускается = меньше возможностей для нестабильных падений на PR.

Пропорционально сокращению тестов
Logical inference + test execution data
Карта метрик — Stanislav Belyaev · Анализ — Anthropic Claude Opus 4.6 · Все данные проверены человеком