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

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

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

Тестам часто нужно временно подменять переменные окружения, не оставляя изменения после завершения. t.Setenv решает эту задачу автоматически: сохраняет прежнее состояние, устанавливает новое значение и регистрирует восстановление через механизм очистки теста.

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

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

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

В Go тестовый пакет явно запрещает вызов t.Setenv в параллельном тесте. Это не просто рекомендация: нарушение ограничения приводит к аварийному завершению соответствующего теста, поэтому проблему нельзя исправить ожиданием или проверкой порядка выполнения.

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

Сначала нужно определить, действительно ли тест проверяет поведение, зависящее от окружения. Если да, такой тест следует оставить непараллельным и позволить t.Setenv восстановить состояние автоматически.

package config

import (
	"os"
	"testing"
)

func TestModeFromEnv(t *testing.T) {
	t.Setenv("APP_MODE", "test")
	if got := os.Getenv("APP_MODE"); got != "test" {
		t.Fatalf("режим: %q", got)
	}
}

t.Setenv регистрирует восстановление значения, включая случай, когда переменная до теста отсутствовала. Это снижает риск загрязнения следующих тестов, но не делает изменение окружения локальным и не разрешает параллельный доступ.

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

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

В наборе тестов конфигурации часть сценариев читала APP_MODE, а остальные могла выполнять параллельно. Попытка добавить t.Parallel в тест с t.Setenv сразу приводила к панике.

Рассматривались три варианта: защищать изменения глобальной блокировкой, оставить тест последовательным или изменить API конфигурации так, чтобы режим передавался явно. Блокировка была отвергнута: она защищала бы только тесты, использующие ту же блокировку, но не код или тесты, которые читают окружение напрямую.

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

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

Можно ли вызвать t.Setenv в обычном тесте, а затем запустить параллельный subtest?

Это опасная схема. Изменение окружения, установленное родительским тестом, действует на весь процесс и может сохраняться, пока выполняется параллельный subtest. Даже если сам вызов t.Setenv произошёл до t.Parallel, параллельный код всё равно получает доступ к глобальному состоянию. Надёжнее не использовать окружение для передачи данных в параллельный subtest, а передать значение явно.

Что произойдёт при нескольких вызовах t.Setenv для одной переменной в одном тесте?

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

Почему mutex вокруг t.Setenv не является полноценным решением?

Блокировка может сериализовать только код, который добровольно использует именно этот mutex. Любой другой тест или библиотека может прочитать переменную вне критической секции и увидеть временное значение. Кроме того, блокировка не превращает окружение в локальное состояние; для параллельных unit-тестов лучше применять явную передачу конфигурации, а для проверки поведения процесса — отдельный процесс.