Фаззинг и бенчмарки: входы по покрытию, b.Loop и честность через benchstat

Нативный фаззинг: сиды, мутация и корпус

С Go 1.18 фаззинг встроен в go test. Фазз-таргет — функция FuzzXxx(f *testing.F): сид-входы регистрируются через f.Add, затем f.Fuzz получает свойство, обязанное выполняться для любого входа:

func FuzzParseInterval(f *testing.F) {
	f.Add("90s")
	f.Add("2h45m")
	f.Add("")
	f.Fuzz(func(t *testing.T, s string) {
		d, err := ParseInterval(s)
		if err != nil {
			return // невалидный вход можно отклонить — но нельзя паниковать
		}
		// свойство round-trip: форматируем распарсенное и парсим снова
		s2 := FormatInterval(d)
		d2, err := ParseInterval(s2)
		if err != nil || d2 != d {
			t.Fatalf("round-trip сломан: %q -> %v -> %q -> %v (%v)", s, d, s2, d2, err)
		}
	})
}

Без -fuzz go test просто прогоняет сиды плюс закоммиченный корпус — дёшево, детерминированно, дружелюбно к CI. С go test -fuzz=FuzzParseInterval движок мутирует входы по покрытию: вход, достигший новой ветки, сохраняется и мутируется дальше, так что поиск концентрируется на коде, которого движок ещё не видел, — обычно десятки тысяч прогонов в секунду на воркер. Этот механизм и объясняет, почему фаззинг находит то, что таблицам недоступно: таблица кодирует примеры, которые автор вообразил; фаззер исследует пространство входов, на котором код реально ветвится, — знак без цифр, одинокие байты-продолжения UTF-8, 1e309. Когда вход падает, движок его минимизирует (ужимает, пока падение воспроизводится) и пишет в testdata/fuzz/FuzzParseInterval/ — закоммитьте файл, и краш становится постоянным регрессионным тестом, который обычный go test гоняет без флагов. Мастерство — в свойстве: паники ловятся бесплатно, но «не паникует» — слабое свойство; round-trip (parse∘format = id), сверка с эталонной реализацией и инварианты (длина вывода, отсортированность) — вот где фаззинг зарабатывает свою сеньорскую цену.

Бенчмарки: b.Loop, ns/op, allocs/op

Глядя на результат бенчмарка, как понять: вы измеряете стоимость вашей функции или стоимость пустого цикла, который компилятор давно удалил? У этого вопроса есть точный ответ — и в Go 1.24 он изменился.

Бенчмарк — это BenchmarkXxx(b *testing.B), запускаемый через go test -bench=.. С Go 1.24 цикл пишется как b.Loop():

func BenchmarkParseInterval(b *testing.B) {
	b.ReportAllocs()
	input := strings.Repeat("1h30m", 1) // сетап — вне цикла
	for b.Loop() {
		d, err := ParseInterval(input)
		if err != nil {
			b.Fatal(err)
		}
		_ = d
	}
}

b.Loop закрывает две хронические лжи старого стиля for i := 0; i < b.N; i++. Первая — устранение мёртвого кода: компилятор может заметить, что результат не используется, и удалить вызов — старым бенчмаркам требовались пакетные sink-переменные; b.Loop автоматически держит аргументы и результаты тела цикла живыми. Бенчмарк, рапортующий 0.25 ns/op, измеряет стоимость пустого цикла, а не вашей функции. Вторая — амортизация сетапа: стиль b.N перезапускал всю функцию с растущим N (1, 100, 10000…), пока прогон не превышал -benchtime (по умолчанию 1 с), повторяя сетап каждый раунд, если вы не вспомнили про b.ResetTimer; b.Loop выполняет сетап ровно один раз и замеряет только цикл. Числа: ns/op — стенное время на итерацию; -benchmem или b.ReportAllocs() добавляют B/op и allocs/op — счётчики аллокаций точны (берутся из счётчиков аллокатора рантайма) и обычно являются самым стабильным и самым действенным числом бенчмарка: срезать allocs/op с 7 до 1 — реальная победа независимо от шума таймера.

benchstat: статистическая честность

Одиночный прогон «до/после», доказывающий, что ваша оптимизация дала «на 4% быстрее», не доказывает ничего. Бенчмарки стенного времени на реальных машинах гуляют — тепловой троттлинг, миграция между ядрами, раскладка кэшей и ASLR, вкладка браузера — легко ±2–5% на ноутбуке и хуже на разделяемых CI-раннерах. Честный протокол: прогнать каждую сторону ~10 раз и отдать статистику benchstat:

// go test -bench=ParseInterval -count=10 > old.txt
// ... применяем изменение ...
// go test -bench=ParseInterval -count=10 > new.txt
// benchstat old.txt new.txt
//
//             │   old.txt   │             new.txt              │
// ParseInterval  412.5n ± 2%   369.0n ± 1%   -10.55% (p=0.000 n=10)
// (незначимое изменение печатается как: ~ , p=0.483)

benchstat сообщает медиану, разброс и p-value по критерию Манна — Уитни; если распределения статистически неразличимы, вместо дельты печатается ~. Эта тильда и есть фича: она не даёт выдать шум за победу. Дисциплина, удерживающая числа честными: тихая машина или выделенный раннер, -count=10, сначала сравнивать allocs/op (точные) и бенчмаркать тот уровень, который чувствуют пользователи — выигрыш 30% в функции, занимающей 0.1% профиля, — погрешность округления; потому бенчмарки идут в паре с pprof, а не вместо него.