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