Ответ.

Flaky-тесты — это тесты, которые могут проходить или падать без изменений в коде, из-за случайных внешних факторов. Они подрывают доверие к автоматизации и затрудняют CI/CD процессы.

История вопроса: Напряженность с flaky-тестами возникла с появлением массовых E2E, интеграционных и UI-тестов, когда стабильность окружения и зависимых сервисов не гарантирована. Поначалу такие сбои игнорировали или "перезапускали руками".

Проблема:

Flaky-тесты делают автоматический прогон тестов ненадежным.
Разработчики начинают пропускать настоящие сбои, считая их ложными.
Растет время поддержки тестов и требуется ручная разборка нестабильных результатов.

Решение:

Отдельный учёт flaky-тестов. Лейблируют (например, @FlakyTest) или выносят в отдельную категорию.
Автоматическое переисполнение. В случае падения теста повторяют его X раз — если падает не всегда, тест помечают нестабильным.
Анализ причин нестабильности: использование логов, слепков состояния, мониторинга ресурсов (например, нестабильная сеть, очереди или работа GC).
Постепенное исправление: работа с тестовым окружением, упрощение сценариев, мокинг нестабильных зависимостей.

Пример кода для авто-ретрая:

import pytest
@pytest.mark.flaky(reruns=3, reruns_delay=2)
def test_random_fail():
    ... # test code

Ключевые особенности:

Важно отделять flaky-тесты от настоящих падений
Не следует просто "ретраить всё" — настоящие баги не должны пропускаться
Регулярно анализируется и документируется статус теста, а не замалчивается

Вопросы с подвохом.

Flaky-тесты — это всегда проблема инфраструктуры?

Нет, flaky могут быть вызваны ошибками бизнес-логики, гонками в коде, асинхронностью или неправильной работой с временем.

Достаточно ли просто перезапускать упавшие тесты?

Нет, ретраи лишь маскируют проблему. Необходимо искать и устранять причину.

Стоит ли удалять все нестабильные тесты?

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

Типовые ошибки и анти-паттерны

Игнорирование flaky, что приводит к пропуску серьёзных багов.
Массовый ретрай без анализа причин.
Маркировка важных тестов как flaky без действия по их исправлению.

Пример из жизни

Негативный кейс

В проекте flaky тесты просто маркировали и больше не трогали, считая проблему "нерешаемой".

Плюсы:

Снижение числа ложных "красных" сборок

Минусы:

Реальные баги уходят в прод
Постоянная ручная проверка результатов

Позитивный кейс

Для каждого нестабильного теста ввели автоматический ретрай и внутренний учёт нестабильности. Проводили регулярное совместное ревью причин и фиксили баги по мере их накопления.