Табличные тесты и сабтесты: кейсы как данные, t.Run и почему в Go нет assert-библиотеки

Кейсы как данные: таблица из анонимных структур

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

func TestParseSize(t *testing.T) {
	tests := []struct {
		name    string
		in      string
		want    int64
		wantErr bool
	}{
		{name: "plain bytes", in: "512", want: 512},
		{name: "kilobytes suffix", in: "4K", want: 4096},
		{name: "rejects negative", in: "-1K", wantErr: true},
		{name: "rejects empty", in: "", wantErr: true},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			got, err := ParseSize(tt.in)
			if (err != nil) != tt.wantErr {
				t.Fatalf("ParseSize(%q) error = %v, wantErr %v", tt.in, err, tt.wantErr)
			}
			if got != tt.want {
				t.Errorf("ParseSize(%q) = %d, want %d", tt.in, got, tt.want)
			}
		})
	}
}

Выигрыш структурный. Добавить случай — одна строка, поэтому граничные случаи действительно добавляют: предельная стоимость теста номер 24 почти нулевая, тогда как копипастная функция стоит пятнадцать строк и имя. Меняется и ревью: PR, трогающий поведение, виден как изменённые строки таблицы, и ревьюер сканирует её на предмет недостающего случая, а не диффает прозу. Острый край один: если строки делят изменяемое состояние (пакетная фикстура, переиспользуемый буфер), порядок прячет связанность. Некоторые команды берут map[string]testCase именно потому, что Go рандомизирует обход map — межкейсовые зависимости тогда падают громко, а не тихо проходят в порядке среза.

Сабтесты: адресуемые, фильтруемые, параллельные

t.Run делает каждую строку полноценным сабтестом: он выполняется в своей горутине, падает независимо (t.Fatal убивает только эту строку) и получает адресуемое имя — пробелы заменяются подчёркиваниями, так что упавший случай выше достижим напрямую:

// Перезапустить ровно одну строку, не трогая код:
//   go test -run 'TestParseSize/rejects_negative'
// Всё под одним тестом:
//   go test -run 'TestParseSize' -v

В реальных сьютах важны две доводки. Первая — t.Helper(): вызовите его в начале любого общего хелпера-проверки, и падение будет привязано к строке вызывающего, а не внутри хелпера; без него тридцать падений указывают на helpers.go:12, и отчёт бесполезен. Вторая — t.Parallel() внутри замыкания сабтеста распараллеливает строки: родительский тест возвращается, припаркованные сабтесты возобновляются вместе, а -parallel ограничивает конкурентность. Историческая ловушка: до Go 1.22 переменная цикла tt была общей на весь цикл, так что все параллельные сабтесты захватывали одну переменную и проверяли последнюю строку — сьюты годами были зелёными, гоняя один случай N раз. Go 1.22 сделал переменные цикла per-iteration и закрыл класс багов, но в старых кодовых базах вы ещё встретите строки-тени tt := tt — это окаменелости той ловушки, а не карго-культ.

got/want, cmp.Diff и golden-файлы — позиция без assert

Прежде чем тянуться к сторонней assertion-библиотеке, спросите себя: какое сообщение об ошибке вы прочтёте в два часа ночи, когда CI красный и никакого контекста нет? Этот вопрос и объясняет, почему Go не поставляет assert.Equal (библиотеку для проверок равенства в тестах).

В stdlib нет assert.Equal — сознательно. Позиция Go FAQ: assert-DSL уводят поток управления во фреймворк, поощряют тесты, умирающие на первой проверке, и выдают сообщения на языке фреймворка, а не на вашем. Тест — обычная программа на Go: if got != want плюс t.Errorf с обоими значениями. Масштабируется это за счёт дисциплины формата — f(input) = got, want want, — чтобы строка лога CI диагностировалась без открытия файла. Для структур, срезов и map ручное сравнение тонет; де-факто стандарт — go-cmp:

if diff := cmp.Diff(want, got); diff != "" {
	t.Errorf("ParseConfig() mismatch (-want +got):\n%s", diff)
}

cmp.Diff печатает минимальный построчный дифф только различающихся полей — на структуре в 40 полей это разница между полезным падением и двумя стенами %+v. По умолчанию он паникует на неэкспортируемых полях (это фича: вынуждает объявить семантику сравнения через cmpopts.IgnoreUnexported или метод Equal). Когда велик сам вывод — отрендеренные шаблоны, сгенерированный SQL, маршалённый JSON — табличный паттерн расширяется golden-файлами: ожидаемые байты лежат в testdata/case.golden, тест сравнивает с ними, а перегенерация идёт через флаг -update, читаемый через flag.Bool. Дифф golden-файла попадает в код-ревью как настоящее изменение файла — в этом и смысл: новый ожидаемый вывод утверждает человек.