testing пакет
Тема дорожной карты · Golang
Пакет testing — встроенный фреймворк Go для юнит-тестирования и бенчмаркинга, предоставляющий типы testing.T, testing.B и testing.F, которые управляют каждым тестом, бенчмарком и фаззинг-целью, компилируемыми и запускаемыми через go test. testing.T предоставляет t.Error, t.Errorf, t.Fatal, t.Fatalf, t.Log, t.Run для подтестов, t.Parallel для параллельного выполнения тестов и t.Cleanup для регистрации функций завершения, выполняемых после теста вне зависимости от результата. testing.B — тип бенчмарка, чьё поле b.N автоматически настраивается раннером go test -bench, а b.ReportAllocs() совместно с b.ResetTimer дают точные данные о выделениях памяти на операцию, питающие решения по оптимизации производительности Go. В Go 1.18 пакет testing получил testing.F для фаззинга: f.Add(seed) предоставляет начальные записи корпуса, а go test -fuzz=FuzzXxx генерирует случайные входные данные для обнаружения паник и сбоев в Golang-парсерах, сериализаторах и обработчиках протоколов. Понимание каждой возможности пакета testing — обязательное условие, прежде чем обращаться к testify, gomock или любой другой сторонней Golang-библиотеке тестирования.
Как это работает
testing пакет использует stdlib testing-пакет — фреймворк не нужен. Файлы заканчиваются на _test.go; тесты — func TestX(t *testing.T); subtests через t.Run. Table-driven тесты — идиоматический паттерн. Бенчмарки: func BenchmarkX(b *testing.B), запуск go test -bench=.. Моки: опирайтесь на маленькие интерфейсы (Go-интерфейсы duck-typed — легко заменить stub); gomock или mockery — для генерируемых моков. testify — для fluent-ассертов, httptest — для тестов HTTP-handlers.
Когда применять
Table-driven тесты — дефолт: читаемы, легко добавить кейсы. httptest.Server — для тестов HTTP-клиентов; httptest.ResponseRecorder — для тестов handlers. В CI — с -race. testify — если команда предпочитает fluent-ассерты; иначе stdlib t.Errorf достаточен. dockertest или testcontainers-go — для тестов с реальной БД.
Типичные ошибки
Ловушки testing пакет: параллельные тесты (t.Parallel()), делящие state (тонкие race conditions); бенчмарки, оптимизируемые компилятором (присваивайте результаты пакетной sink-переменной); нет -race в CI (data race проскакивают в production); over-mocking — тесты проверяют детали реализации, не поведение.