Где пишутся юнит-тесты

Что проверяют

Знаете ли вы соглашения Go, а не общие слова про тестирование. Главное: где лежат файлы и какой пакет у тестов. Следом обычно спрашивают про табличные тесты и про то, как тестировать неэкспортируемые функции.

Как отвечать

В Go юнит-тесты лежат рядом с кодом, в той же директории, в файлах с суффиксом _test.go: user.go и user_test.go. Обычный go build такие файлы игнорирует, в бинарник они не попадают, а go test находит их сам.

Дальше важный выбор пакета:

• package user: тест в том же пакете, видит неэкспортируемые функции и поля. Это тестирование «белого ящика»;
• package user_test: внешний тестовый пакет в той же директории. Видит только публичный API, как настоящий потребитель, и помогает избежать циклов импорта. Если нужно открыть пару внутренних деталей, заводят export_test.go в основном пакете: он тоже компилируется только при тестах;
• testdata/: каталог для фикстур, инструменты Go его игнорируют при сборке.

Сигнатура теста func TestXxx(t *testing.T), рядом живут BenchmarkXxx(b *testing.B), ExampleXxx для документации и FuzzXxx(f *testing.F) для фаззинга. Идиоматичная форма это табличный тест: срез структур с входом и ожиданием и цикл с t.Run(tc.name, ...), так каждый кейс становится отдельным подтестом.

Запуск: go test ./... по всему модулю, -run для фильтра по имени, -race для детектора гонок, -cover для покрытия. Интеграционные тесты часто отделяют build-тегом //go:build integration или проверкой testing.Short().

Где спотыкаются

Переносят привычку из Java и складывают тесты в отдельную папку tests/. Тогда это отдельный пакет: неэкспортируемое недоступно, и хелперы из основного кода приходится делать публичными ради тестов.

Не знают про кэш тестов: повторный go test ./... показывает (cached), и кандидат думает, что тест не запускался. Принудительный прогон даёт флаг -count=1.

Считают testify частью стандартной библиотеки. Это сторонний пакет, и в ответе сначала нужен testing, а потом уже удобные обёртки.