Как перезапустить Flaky тест?

Стратегия работы с Flaky-тестами в автоматизации

Flaky-тест — это тест, который периодически завершается то успехом, то провалом при одних и тех же условиях выполнения. Это одна из самых опасных проблем в автоматизации, поскольку подрывает доверие ко всей тестовой системе. Никогда не следует просто перезапускать flaky-тест без анализа корневой причины. Слепой перезапуск маскирует проблемы, которые со временем усугубляются.

План действий при обнаружении Flaky-теста

1. Немедленная изоляция и маркировка

Первым делом тест нужно изолировать от основного прогона, чтобы он не блокировал пайплайн и не портил метрики. В большинстве фреймворков для этого используются аннотации.

// Пример в JUnit 5
@Tag("Flaky")
@Disabled("Investigate flakiness: ID-1234")
@Test
void shouldProcessOrderCorrectly() {
    // тестовая логика
}

# Пример в Pytest
import pytest

@pytest.mark.flaky(reruns=2)  # Временное решение!
@pytest.mark.skip(reason="Flaky - JIRA ticket AUTO-456")
def test_user_registration():
    # тестовая логика

2. Глубокий анализ первопричины

Flaky-тест — это всегда симптом, а не самостоятельная болезнь. Основные причины:

• Проблемы с синхронизацией и временем: Ожидания недостаточны для асинхронных операций.
• Состояние окружения: Зависящие от внешних сервисов, данных или времени тесты (например, использующие текущую дату).
• Утечки состояния: Общие ресурсы между тестами (статичные переменные, кэш, база данных).
• Нестабильная инфраструктура: Проблемы с сетью, памятью, диском в CI/CD среде.
• Сложные UI-интерракции: Анимации, динамические элементы в Selenium-тестах.

3. Временные решения: "Умные" перезапуски

Если тест нужно срочно вернуть в прогон до полного исправления, используйте специализированные инструменты с лимитом попыток и логированием:

• Для JUnit 5: Библиотека junit-rerunner или @RepeatedTest.
• Для Pytest: Встроенный плагин pytest-rerunfailures.
• Для TestNG: Параметр retryAnalyzer.

Важно: Такие перезапуски должны быть временной мерой и сопровождаться тикетом на исправление.

// Пример "умного" перезапуска с TestNG
public class RetryAnalyzer implements IRetryAnalyzer {
    private int count = 0;
    private static final int MAX_RETRY = 2;

    @Override
    public boolean retry(ITestResult result) {
        if (count < MAX_RETRY) {
            count++;
            System.out.println("Retrying test " + result.getName() + ", attempt " + count);
            return true;
        }
        return false;
    }
}

@Test(retryAnalyzer = RetryAnalyzer.class)
public void flakyUITest() {
    // тестовая логика
}

4. Долгосрочные стратегии: Профилактика и стабилизация

• Детерминированные ожидания: Замена Thread.sleep() на явные ожидания (WebDriverWait в Selenium).
• Изоляция тестов: Каждый тест должен создавать свои данные и чистить за собой.
• Стабильные локаторы: Использование уникальных, неизменяемых атрибутов для поиска элементов.
• Моки и стабы: Изоляция от нестабильных внешних зависимостей.
• Параллельная стабильность: Проверка, что тесты не влияют друг на друга при параллельном запуске.

# Пример замены sleep на явное ожидание в Selenium
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.common.exceptions import TimeoutException

def wait_for_element(driver, locator, timeout=10):
    try:
        element = WebDriverWait(driver, timeout).until(
            EC.presence_of_element_located(locator)
        )
        return element
    except TimeoutException:
        # Логирование и осмысленное падение
        raise AssertionError(f"Element {locator} not found in {timeout} seconds")

5. Организационные практики

• Вести "Hall of Flaky": Общий реестр нестабильных тестов с приоритетами исправления.
• Метрики и дашборды: Отслеживать процент flaky-тестов как ключевой показатель здоровья автотестов.
• Код-ревью с фокусом на стабильность: Обращать особое внимание на потенциальные причины нестабильности при ревью.
• Регулярные "дни стабилизации": Выделять время на расследование и исправление flaky-тестов.

Вывод: Перезапуск flaky-теста — это тактическое действие в рамках стратегической борьбы за стабильность. Нужна нулевая терпимость к flaky-тестам: каждый такой тест должен расследоваться, фиксироваться во временном решении и обязательно исправляться на уровне архитектуры или кода. Слепые повторные запуски без анализа — путь к деградации ценности вашей автоматизации.