В тестовом наборе результат зависит от порядка запуска, но при последовательном прогоне это незаметно. Какой механизм поможет выявить скрытую зависимость тестов?
Используйте случайную перестановку порядка тестов с сохранением и публикацией начального значения генератора — seed. Если тест падает только при определённом порядке, сохранённый seed позволит воспроизвести последовательность и найти скрытое взаимодействие между тестами.
Перемешивание не устраняет проблему само по себе: это диагностический механизм. После обнаружения зависимости нужно сделать тесты независимыми или явно оформить допустимую общую фикстуру.
По мере роста автотестов фиксированный порядок запуска часто становится неявным контрактом. Один тест может оставлять данные, изменять глобальную настройку, использовать общий кэш или влиять на состояние процесса, а следующий тест начинает молча рассчитывать на этот результат.
Случайный порядок появился как практический способ обнаруживать такие зависимости раньше, чем они проявятся при изменении структуры набора, параллелизации или переходе на другой исполнитель тестов.
При фиксированном порядке тесты могут проходить локально и в CI, хотя фактически не являются независимыми. Перестановка файлов, добавление нового теста или изменение числа потоков тогда вызывает труднообъяснимые падения.
Простые повторные запуски не всегда помогают: они могут каждый раз воспроизводить один и тот же порядок и скрывать дефект. Неверный подход также опасен тем, что команда начнёт считать случайное прохождение доказательством исправности набора.
Тестовый исполнитель перемешивает тесты перед запуском и фиксирует использованный seed в логе результата. При сбое команда повторяет прогон с тем же seed, получает ту же последовательность и исследует границу между последним успешно завершившимся тестом и первым упавшим.
Полезный процесс выглядит так:
Важно отличать случайный порядок от случайного поведения. При одинаковом seed порядок должен быть воспроизводимым, иначе диагностика превращается в новый источник нестабильности.
Перемешивание не заменяет очистку данных, изоляцию процессов и контроль параллельного доступа. Оно также может быть неудобно для отладки большого набора, поэтому в отчёте нужно хранить не только seed, но и фактический порядок тестов.
Есть компромисс между частотой и стоимостью проверки. Перемешивать каждый запуск полезно для небольших быстрых наборов, а для дорогого регресса можно использовать разные seed по расписанию и обязательно повторять исходный порядок при каждом падении.
После добавления нового теста проверки заказов начали периодически падать с сообщением о уже существующем заказе. Фиксированный CI-порядок скрывал проблему: один из старых тестов оставлял запись с одинаковым идентификатором, а новый тест иногда запускался после него.
Рассматривались три варианта. Закрепить новый тест первым было быстро, но лишь сохранило скрытую связанность. Полная очистка базы после каждого теста давала сильную изоляцию, но существенно увеличивала время прогона. Случайная перестановка с seed позволила быстро подтвердить зависимость, после чего тестовые идентификаторы сделали уникальными, а подготовку данных — независимой от предыдущих сценариев.
В результате перемешивание оставили как регулярную проверку, а seed и порядок тестов добавили в отчёт CI. Это одновременно обнаруживало новые зависимости и позволяло воспроизводить уже найденные сбои.
Нет. Один случайный порядок проверяет только одну перестановку и не даёт гарантии обнаружения зависимости. Нужны разные seed, регулярный повтор прогонов и обязательное сохранение seed для каждого сбоя.
При этом количество перестановок не превращает тестирование в математическое доказательство независимости. Это вероятностный способ повысить шанс обнаружения проблемы, который должен дополняться правильной изоляцией.
Обычно это плохое решение. Фиксация порядка маскирует связанность и создаёт новый неявный контракт: любое изменение набора может снова нарушить его.
Допустимо явно задавать порядок только там, где зависимость является частью специально спроектированной последовательности, например в ограниченном сценарии миграции. Для обычных независимых тестов нужно устранить общий изменяемый ресурс или корректно управлять его жизненным циклом.
Нужно повторить сбой с тем же seed. Если воспроизводится та же последовательность и тот же тест падает после тех же предшественников, это сильный признак зависимости от порядка.
Если одинаковый seed не воспроизводит сбой, следует дополнительно исследовать время, сеть, конкуренцию, внешние сервисы и случайные входные данные. Поэтому в отчёте должны фиксироваться не только порядок тестов, но и другие параметры, влияющие на воспроизводимость.