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