Table-driven тесты
Тема дорожной карты · Golang
Табличные тесты в Go — идиоматичный паттерн для написания исчерпывающих тестовых наборов в Golang: слайс анонимных структур определяет пары входных/выходных данных, а единственный цикл for _, tc := range tests прогоняет каждый кейс через одно и то же тело функции с testing.T. Каждая запись в таблице тестов, как правило, включает поля name, input, want и опционально wantErr, а вызов t.Run(tc.name, func(t *testing.T) {...}) создаёт подтест для каждой строки, который можно адресовать командой go test -run TestFoo/case_name. Табличные тесты в Go естественно сочетаются с хелперами библиотеки testify — assert.Equal и require.NoError, — устраняя шаблонный код кастомных сообщений об ошибках и делая намерения утверждений кристально чёткими для ревьюеров. Паттерн масштабируется от чистых юнит-тестов — валидация функции парсинга — до интеграционных тестов, выполняющих запросы pgx или sqlx к тестовой базе данных, в рамках одного вызова go test ./.... Запуск табличных тестов с go test -race ./... и go test -cover ./... даёт Golang-командам гарантии безопасности конкурентности и метрики покрытия одновременно, обеспечивая уверенный рефакторинг интерфейсов, структур и HTTP-middleware.
Как это работает
Table-driven тесты использует 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 — для тестов с реальной БД.
Типичные ошибки
Ловушки Table-driven тесты: параллельные тесты (t.Parallel()), делящие state (тонкие race conditions); бенчмарки, оптимизируемые компилятором (присваивайте результаты пакетной sink-переменной); нет -race в CI (data race проскакивают в production); over-mocking — тесты проверяют детали реализации, не поведение.