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

state = {"count": 0}

def test_increment():
    state["count"] += 1
    assert state["count"] == 1

def test_initial_state():
    assert state["count"] == 0

Краткий ответ

Проблема вызвана утечкой состояния между тестами: test_increment изменяет общий объект state, а test_initial_state ожидает его исходное состояние. Нарушено свойство изоляции тестов — каждый тест должен давать один и тот же результат независимо от порядка запуска и выполнения соседних тестов.

Исторический контекст

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

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

Постановка проблемы

Если сначала выполнить test_increment, глобальный словарь станет равен {"count": 1}, поэтому test_initial_state завершится ошибкой. При отдельном запуске test_initial_state может проходить, создавая ложное впечатление, что тест или продукт работают корректно.

Такие проверки становятся order-dependent — зависящими от порядка запуска. Это снижает воспроизводимость, может вызывать нестабильные падения в CI и затрудняет определение виноватого изменения: падение обнаруживается в одном тесте, а причина находится в другом.

Подробное решение

Перед каждым тестом нужно создавать или восстанавливать независимое начальное состояние. Для данного примера достаточно инициализировать state заново перед каждым тестом:

def make_state():
    return {"count": 0}

def test_increment():
    state = make_state()
    state["count"] += 1
    assert state["count"] == 1

def test_initial_state():
    state = make_state()
    assert state["count"] == 0

В реальном проекте это обычно реализуют через setup/teardown, фикстуры или фабрики тестовых данных. Для базы данных применяют транзакции с откатом, очистку созданных записей или отдельную схему; для файлов — временные каталоги; для внешних сервисов — контролируемые заглушки и моки.

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

Полная изоляция повышает стоимость и время выполнения. Например, отдельная база или процесс надёжнее общей фикстуры, но требует больше ресурсов. Компромисс выбирают по типу ресурса и риску: дешёвые объекты создают заново, а дорогие общие ресурсы используют только при строгом контроле состояния и запрете зависимости тестов друг от друга.

Ситуация из практики

Интеграционный набор для заказов периодически падал в CI на проверке пустой корзины. Рассматривались три варианта: случайно перемешивать тесты, очищать корзину только в проблемном тесте или создавать отдельного пользователя и очищать его данные после каждого теста.

Перемешивание помогало обнаружить зависимость, но не устраняло её. Локальная очистка была дешевле, однако не учитывала другие оставшиеся данные. Выбрали отдельного пользователя на тест и гарантированную очистку данных в teardown: это снизило риск пересечения тестов и сохранило приемлемое время выполнения.

Дополнительно в CI включили запуск тестов в разных порядках. Это не заменяет изоляцию, но помогает выявлять скрытые зависимости до их проявления на случайном наборе изменений.

Что кандидаты часто упускают

1. Достаточно ли просто запускать тесты в случайном порядке?

Нет. Случайный порядок — диагностический приём, а не исправление. Он повышает вероятность обнаружить зависимость, но тесты по-прежнему могут влиять друг на друга. Исправление состоит в управлении состоянием и восстановлении независимого начального условия.

2. Всегда ли общий read-only объект нарушает изоляцию?

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

3. Почему сброс состояния после теста не всегда достаточен?

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