На что реально влияет параметр параллелизма Go-тестов, если часть тестов вызывает t.Parallel?
Он ограничивает максимальное число параллельных тестов и под-тестов, допущенных тестовым фреймворком к одновременному выполнению внутри одного тестового процесса. Он не ограничивает количество горутин, созданных внутри одного теста, и не задаёт число одновременно тестируемых пакетов.
Параллельный запуск тестов нужен, чтобы ускорить большие наборы проверок без ручного управления их расписанием. В Go тест явно помечается как параллельный, а фреймворк получает возможность планировать такие тесты и ограничивать их совокупную конкуренцию.
Такой подход отделяет решение теста «его можно запускать параллельно» от решения инфраструктуры «сколько таких тестов допустимо выполнять одновременно».
Если разрешить всем параллельным тестам выполняться без ограничения, они могут перегрузить CPU, память, файловую систему, базу данных или внешние сервисы. Слишком маленький лимит, напротив, уменьшит выигрыш от параллельного запуска и увеличит общее время набора.
Важно не путать разные уровни параллелизма. Ограничение тестового фреймворка действует внутри одного процесса тестов; запуск нескольких пакетов регулируется отдельным механизмом, а горутины приложения вообще не становятся его участниками автоматически.
Тест, вызвавший t.Parallel, регистрируется как допускающий параллельное выполнение. После того как его родительский контекст позволит продолжить выполнение, тест становится кандидатом на запуск; фреймворк не допускает одновременно больше параллельных тестов, чем задано лимитом.
Лимит считается для параллельных тестов и под-тестов в данном тестовом процессе. Он не означает, что внутри каждого теста будет только одна горутина или что все операции приложения будут принудительно сериализованы.
Например, один параллельный тест может создать десятки горутин. Параметр параллелизма не ограничит их количество, поэтому защиту общей памяти, соединений и других ресурсов всё равно должен обеспечивать сам тест или тестируемый код.
Не следует смешивать этот параметр с GOMAXPROCS. GOMAXPROCS определяет, сколько логических процессоров может одновременно использовать планировщик Go для выполнения Go-кода, тогда как лимит тестов ограничивает число тестовых единиц, допущенных фреймворком к параллельному выполнению. Также это не то же самое, что параметр, управляющий одновременным запуском отдельных пакетов.
Практический компромисс таков: лимит выбирают с учётом CPU и памяти, но прежде всего — с учётом внешних ограниченных ресурсов. Увеличение значения не исправляет тесты, которые используют общий временный каталог, глобальные переменные или общий сервер без изоляции.
В CI набор из 400 тестов содержит много под-тестов с t.Parallel. При высоком лимите сборка ускоряется, но периодически появляются ошибки подключения к тестовой базе и конфликты имён файлов.
Можно полностью отключить параллельность. Это делает результат стабильнее, но скрывает проблемы изоляции и заметно увеличивает время обратной связи. Можно также оставить высокий лимит и увеличить ресурсы CI, однако это не устранит конфликтов, если тесты используют общие данные.
Правильное решение — сначала изолировать временные каталоги и данные базы, затем подобрать ограничение по фактической ёмкости CI-окружения. В результате параллельность сохраняет ускорение, а лимит предотвращает перегрузку; оставшиеся ошибки становятся сигналом о нарушении изоляции, а не случайным эффектом расписания.
Ограничивает ли этот параметр число одновременно выполняющихся горутин?
Нет. Он ограничивает тестовые функции и под-тесты, которыми управляет пакет testing. Горутины, созданные тестом или тестируемым кодом, планируются обычным рантаймом Go и могут значительно увеличить фактическую нагрузку.
Равен ли лимит параллельных тестов числу ядер?
Нет. Число ядер влияет на возможную физическую одновременность выполнения, но лимит тестов — это ограничение количества активных тестовых единиц. Значение можно сделать больше числа ядер, например если тесты преимущественно ждут сеть или диск, но это увеличит конкуренцию за память и внешние ресурсы.
Почему увеличение лимита может выявить ошибки, которых не было при последовательном запуске?
Параллельный запуск меняет порядок и перекрытие операций. Тесты, зависящие от общей переменной, фиксированного имени файла, общего порта или незакрытого соединения, начинают взаимодействовать. Это не означает, что планировщик тестов ошибается: обычно такое поведение показывает недостаточную изоляцию или неявную зависимость тестов друг от друга.