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

Такой тест, вероятно, неявно зависит от порядка выполнения кейсов. Порядок обхода map в Go не является гарантированным, поэтому проход или падение теста в зависимости от порядка указывает на скрытое состояние либо другую зависимость между кейсами.

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

Table-driven tests появились как практический способ описывать множество входов и ожидаемых результатов в единой структуре, не дублируя тело теста. Для этого подходят как срезы, так и отображения, но они выражают разные свойства: срез хранит явный порядок, а map — соответствия ключей значениям.

В тестах порядок часто важен не для самой бизнес-логики, а для воспроизводимости диагностики. Поэтому срез обычно лучше подходит для последовательного набора кейсов, тогда как map удобен, когда порядок не имеет значения.

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

Go не обещает фиксированный порядок обхода элементов map. Если один тест изменяет глобальное состояние, общий объект, временный ресурс или результаты предыдущего кейса, разные порядки могут приводить к разным итогам.

Особенно опасен нестабильный тест: локально он может проходить, а в CI — падать, причём повторный запуск иногда меняет результат. Само по себе изменение порядка не является причиной ошибки в production-коде; оно лишь выявляет, что тест или тестируемый код зависит от состояния, которое не должно быть общим.

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

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

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

func TestCases(t *testing.T) {
    cases := map[string]int{"empty": 0, "one": 1, "two": 2}
    names := make([]string, 0, len(cases))
    for name := range cases { names = append(names, name) }
    sort.Strings(names)
    for _, name := range names {
        t.Run(name, func(t *testing.T) {
            got := calculate(name)
            if got != cases[name] { t.Fatalf("got %d", got) }
        })
    }
}

В примере сортировка делает порядок subtests воспроизводимым, но не исправляет зависимость между ними. Для компилируемого варианта нужны импорт sort и реализация calculate; существенный механизм здесь — явная нормализация порядка.

Не стоит механически сортировать кейсы, если тест проверяет последовательный сценарий: это изменит смысл проверки. Также сортировка не делает безопасными параллельные subtests и не устраняет общий изменяемый ресурс.

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

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

Сортировка дала бы воспроизводимый порядок и упростила бы поиск ошибки, но сохранила бы неправильную модель теста. Был выбран второй вариант: создавать конфиг заново внутри каждого subtest и очищать внешние ресурсы после него. После этого перестановка кейсов перестала влиять на результат, а сортировку оставили только там, где важен стабильный порядок отчёта.

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

Доказывает ли один успешный запуск в конкретном порядке, что кейсы независимы?

Нет. Один порядок проверяет только одну последовательность состояний. Для поиска скрытой зависимости полезно запускать кейсы в разных порядках, но окончательное решение — убрать общее изменяемое состояние или явно синхронизировать и изолировать его.

Можно ли использовать map, если порядок кейсов действительно не важен?

Да, при условии что каждый кейс самодостаточен, а проверки не зависят от порядка subtests. Однако порядок сообщений и место падения в отчёте могут быть менее предсказуемыми. Для удобной диагностики ключи можно отсортировать, не выдавая это за исправление логики теста.

Устранит ли переход с map на срез все проявления нестабильности?

Нет. Срез фиксирует порядок обхода, но не устраняет гонки, случайные данные, текущее время, внешние зависимости или утечки состояния между кейсами. Он решает только проблему неопределённого порядка; остальные источники недетерминизма нужно изолировать отдельно.