Ответ.

Механизм повторного выполнения теста (retry) внедряется с целью повышения стабильности тестового пайплайна и борьбы с флейковыми автотестами, но требует разумного подхода.

История вопроса Появился как workaround для временных infrastructural или флейковых ошибок, не связанных с ошибками приложения (нестабильное окружение, проблемы сети, случайные таймауты API). Многие CI/CD-системы сейчас поддерживают встроенный retry.

Проблема Чрезмерный или неконтролируемый retry может скрывать реальные баги или превращать падения в "просто временные явления". Возникают ложноположительные результаты: вроде бы тест прошёл, но баг всё равно есть.

Решение Включайте retry только для нестабильных или external-dependent тестов, используйте теги или маркеры. Фиксированный лимит повторов (1-2 раза). Логируйте все падения и успехи повторных прогонов для анализа причин сбоев.

import pytest

@pytest.mark.flaky(reruns=2, reruns_delay=5)
def test_external_api():
    # Тест, который может фейлиться из-за нестабильности API
    ...

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

Применять точечно и осознанно
Всегда анализировать причины повторов
Не маскировать баги аппа, а только инфраструктурные/flaky

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

Можно ли делать повторный запуск абсолютно всех автотестов в пайплайне?

Это плохая практика: маскируются как реальные баги, так и архитектурные проблемы тестов. Ретрай — крайний случай для некоторых видов тестов.

Что делать, если после 3-х повторных запусков тест всё равно не проходит?

Прекратить запуск и открыть баг на нестабильность/расследование — так выявляются tricky ошибки, требующие рефакторинга.

Если тест проходит со второго раза — значит всё хорошо?

Нет, единственное корректное состояние — стабильное прохождение с первого раза. Проход со второго — индикатор проблемы (флейки или инфраструктура).

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

Неконтролируемое применение retry, скрывающее баги
Отсутствие аналитики причин падений
Использование retry вместо фикса реальных проблем

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

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

Для всего пайплайна Jenkins включили глобальный retry на два запуска. Через месяц баги из-за race condition в коде размазались, а команда считала, что "quality ok". Продукт внезапно стал падать в продакшене из-за тех же багов.

Плюсы:

Были зелёные пайплайны

Минусы:

Баги аппа не выявлялись вовремя
При раскопках сложно понять источник ненадёжности

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

Для категории тестов с внешними API настроили retry только на них (по тегам). Все остальные тесты проходят строго с одного запуска. По логам команды расследуют и фиксируют повторяющиеся фейлы.