Сборка становится красной, кто-то нажимает «перезапустить», она проходит, и все идут дальше. Это кажется безобидным, но ненадежные тесты постепенно разрушают самое ценное, что есть в наборе тестов: доверие к нему людей. Когда сбои обычно являются шумом, возникают и настоящие ошибки.

В этом руководстве рассказывается, почему тесты становятся нестабильными и как правильно устранить каждую причину. Мы запустили демонстрации синхронизации и общего состояния в Python 3.13, и показанные цифры взяты из этих запусков. Это небольшие демонстрации, предназначенные для того, чтобы было легче увидеть недостатки, поэтому ваша собственная частота неудач будет отличаться.

Что такое слоеный тест?

Ненадежный тест дает разные результаты для одного и того же кода. Он проходит при одном запуске и терпит неудачу при следующем, хотя в продукте ничего не изменилось. Возможно, тест ошибочен, или код может содержать реальную периодически возникающую ошибку. Именно из-за этой второй возможности вам не следует просто отмахиваться от них.

Почему ненадежные тесты стоят так дорого

• Потеря доверия. Как только люди начинают считать, что красный означает «вероятно ненадежный», они перестают расследовать реальные неудачи.
• Пустая трата времени. Разработчики часами перезапускают конвейеры и исследуют сбои, не имеющие ничего общего с их изменениями.
• Медленная доставка. Слияния и релизы ждут повторных запусков, что подрывает суть CI/CD.
• Скрытые ошибки. Условия гонки в продукте могут выглядеть так же, как тестовый шум, и именно они мешают работе.

Общие причины с первого взгляда

Причина 1: тайминг и фиксированный сон

Это наиболее распространенная причина. Тест предполагает, что фоновая работа будет завершена после фиксированной задержки. Чтобы увидеть эффект, мы написали небольшой тест, в котором работа занимает до 2 мс, при этом тест перед проверкой ждет всего 1 мс:

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

Решение состоит в том, чтобы дождаться фактического состояния с большим верхним пределом:

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

Мы запускали каждую версию 200 раз:

Результат – больше, чем просто надежность. Фиксированная версия продолжает работать в момент завершения работы, поэтому обычно она также быстрее. Более длительный сон приведет к тому, что первая версия будет выходить из строя реже, но тогда каждый запуск будет медленнее, и она все равно может выйти из строя на загруженной машине CI.

В браузерных тестах применяется тот же принцип. Используйте автоматическое ожидание Playwright или явное ожидание Selenium вместо time.sleep:

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

Причина 2: общее состояние и порядок тестирования.

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

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

Наш запуск подтвердил это, и именно поэтому пакет может работать месяцами, а затем ломаться, когда кто-то добавляет параллельные запуски или плагин случайного порядка. Лечение – изоляция:

• Предоставляйте каждому тесту свежие данные, используя приспособление, которое настраивает и очищает их. В нашем руководстве по pytest показано, как это сделать.
• Создавайте уникальные записи, например электронное письмо со случайным суффиксом, вместо общего «тестового пользователя».
• Оберните тесты базы данных в транзакцию и откатите ее назад, если это позволяют ваши настройки.
• Регулярно запускайте тесты в случайном порядке, чтобы эти проблемы проявлялись раньше.

Причина 3: Даты, часовые пояса и случайность

Тест, который проходит всю неделю, может не пройти в субботу, в полночь или в последний день месяца. Сделайте время входными данными, а не считывайте часы внутри своей логики:

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

Эти тесты дают один и тот же ответ в любой день. Аналогичным образом установите фиксированное начальное значение для случайных значений в тестах и ​​регистрируйте его при использовании случайных данных, чтобы можно было воспроизвести сбой. Не предполагайте определенный порядок наборов, словарей из внешних источников или запросов к базе данных без ORDER BY.

Причина 4: хрупкие селекторы

Тест, который находит кнопку с div:nth-child(3) > span, не работает при любой настройке макета и может завершиться неудачно только для некоторых размеров или вариантов экрана. Отдавайте предпочтение локаторам, основанным на том, что видят пользователи, или специальным атрибутам тестирования. В нашем руководстве по локаторам драматургов объясняется порядок их использования. Анимация — еще один частый источник проблем, поэтому рассмотрите возможность ее отключения в тестовых средах.

Причина 5. Внешние службы и сети.

Если тест вызывает реального платежного провайдера или сторонний API, то его результат зависит от чужого времени безотказной работы и ограничений скорости. Имитируйте эти вызовы для большинства тестов и сохраняйте небольшое количество отдельных проверок контракта с реальным сервисом, чтобы вы все равно могли узнать, если он изменится. Наше руководство по модульному и интеграционному тестированию объясняет, как их разделить.

Как диагностировать шелушащийся тест

1. Подтвердите. Запустите тест несколько раз без изменений. С pytest работает простой цикл оболочки, а плагин, такой как pytest-repeat, дает вам --count=100.
2. Записывайте доказательства. Сохраняйте журналы, снимки экрана и трассировки каждого сбоя. Здесь особенно полезна программа просмотра следов драматурга.
3. Нажмите на условия. Запустите его с ограниченным процессором, параллельно или в случайном порядке. Чем чаще вы будете терпеть неудачу, тем легче будет учиться.
4. Проверьте его в одиночку. Если он всегда проходит в одиночку, но терпит неудачу в наборе, подозревайте общее состояние.
5. Ищите закономерности. Проверьте, какие машины, время суток и соседние тесты задействованы.
6. Проверьте продукт. Честно спросите, может ли это быть настоящей гонкой в ​​вашем приложении.

Являются ли автоматические повторные попытки исправлением?

Повторные попытки являются полезной краткосрочной подстраховкой, но не панацеей. Одна автоматическая повторная попытка в CI может продолжить работу, пока вы проводите исследование, но тест, для прохождения которого требуется повторная попытка, все равно что-то вам говорит. Хуже того, реальная периодическая ошибка продукта, которая дает сбой в 20% случаев, обычно проходит незамеченной при повторной попытке.

Используйте повторы с этими правилами: ограничьте их одним или двумя, записывайте каждый тест, который требует одного, и относитесь к этому списку как к своему списку дел. Тест, отмеченный как «пройденный при повторной попытке», должен считаться проблемой, которую необходимо исследовать, а не успехом.

Командный процесс для нестабильных тестов

1. Измерьте. Отслеживайте, какие тесты терпят неудачу, а затем передайте тот же коммит. Многие инструменты CI и репортеры тестов могут это продемонстрировать.
2. Карантин. Удалите подтвержденный нестабильный тест из блокирующего выполнения, чтобы он перестал всем мешать, но продолжайте запускать его и отслеживать.
3. Назначьте владельца и срок. Карантин без срока становится просто кладбищем.
4. Исправьте или удалите. Если тест не стоит исправлять, удалите его и проверьте, существует ли его покрытие в другом месте.
5. Предотвратить. Перед объединением запустите новые тесты несколько раз. Тест, который проваливается один раз из пятидесяти запусков, лучше поймать сейчас, чем через шесть месяцев.

Относитесь к нестабильному тесту как к приоритетной ошибке, а не как к фоновому шуму. Здесь также применяются серьезность и приоритет, как описано в разделе серьезность и приоритет. Если нестабильность широко распространена, прочитайте о более широких ошибках автоматизации тестирования и подумайте, не слишком ли много тестов у вас на уровне браузера.

Итоги

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

Часто задаваемые вопросы

Продолжайте учиться