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

Нет, pytest не гарантирует смысловой порядок выполнения тестов. Текущий порядок обычно определяется порядком сборки, но на него нельзя надёжно опираться: его могут изменить структура файлов, параметры запуска или плагины. Каждый тест должен быть независимым от результатов и побочных эффектов других тестов.

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

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

Поэтому тестовый фреймворк собирает и запускает тесты как набор отдельных проверок, но не предоставляет порядок как часть контракта поведения теста.

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

Если один тест изменяет глобальное состояние, базу данных, переменные окружения или файлы, а другой ожидает это изменение, набор становится зависимым от порядка. Такой дефект может проявляться только при полном прогоне, повторном запуске или на CI.

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

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

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

Правильное решение — изолировать состояние:

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

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

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

В проекте один тест создавал пользователя, а следующий проверял его наличие. Локально они проходили, потому что обычно собирались в ожидаемом порядке; после добавления нового тестового файла проверка начала падать на CI.

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

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

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

Можно ли считать порядок тестов стабильным, если он несколько раз одинаков в локальном запуске?

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

Как обнаружить скрытую зависимость тестов от порядка?

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

Всегда ли общий ресурс нужно создавать заново для каждого теста?

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