Моки, фейки и интерфейсы: тест-дублёры без тестирования дублёра

Принимайте интерфейсы там, где их потребляете

Сколько методов должен реализовать ваш тест-дублёр? Скорее всего, намного меньше, чем у заменяемого типа — и именно с этого вопроса начинается философия интерфейсов в Go.

Интерфейсы Go удовлетворяются неявно, и это переворачивает привычку к зависимостям из других языков: потребитель объявляет те немногие методы, которые ему нужны, в своём собственном пакете, и любой конкретный тип с этими методами просто подходит — без implements, без общего пакета интерфейсов:

// пакет billing — объявляет, что нужно billing, и ничего больше
type OrderStore interface {
	Get(ctx context.Context, id string) (Order, error)
	Save(ctx context.Context, o Order) error
}

type Charger interface {
	Charge(ctx context.Context, key string, cents int64) error
}

func New(store OrderStore, ch Charger) *Billing { /* ... */ }

Продакшен-обвязка передаёт настоящее хранилище на Postgres; тест передаёт фейк. Держите интерфейсы маленькими — один-три метода. 14-методный интерфейс Repository заставляет каждого дублёра реализовать 14 методов и ничего не говорит читателю о том, чего касается этот код; OrderStore с двумя методами документирует точный контракт. Гошная пословица сжимает это до одной строки: чем больше интерфейс, тем слабее абстракция. Следствие: возвращайте конкретные типы, принимайте интерфейсы — экспорт интерфейса «для мокабельности» со стороны производителя воссоздаёт ту самую джавовую схему, от которой Go спроектирован уходить, и замораживает API под нужды первого потребителя.

Рукописные фейки вместо мок-фреймворков

Мок (gomock, mockery) записывает вызовы и проверяет взаимодействия: этот метод, эти аргументы, этот порядок, столько-то раз. Фейк — маленькая рабочая реализация (map за мьютексом), а тест проверяет состояние:

type fakeStore struct {
	mu     sync.Mutex
	orders map[string]Order
}

func (f *fakeStore) Get(ctx context.Context, id string) (Order, error) {
	f.mu.Lock()
	defer f.mu.Unlock()
	o, ok := f.orders[id]
	if !ok {
		return Order{}, ErrNotFound // соблюдает настоящий контракт
	}
	return o, nil
}

func (f *fakeStore) Save(ctx context.Context, o Order) error {
	f.mu.Lock()
	defer f.mu.Unlock()
	f.orders[o.ID] = o
	return nil
}

Когда вы напишете фейк однажды и будете переиспользовать его в двадцати тестах, заметите кое-что: рефакторинг кода сервиса фейка не ломает. Размен — в долговечности. Фейк кодирует контракт зависимости один раз — not-found возвращает ErrNotFound, Save затем Get делает round-trip — и каждый тест на нём наследует эту реалистичность; рефакторьте код под тестом свободно, фейк ничего не заметит, потому что отвечает честно вне зависимости от того, кто, что и в каком порядке вызывает. Мок кодирует текущую последовательность вызовов тестируемого кода — потому рефакторинги и валят мок-сьюты оптом. У моков остаётся одна легитимная ниша: проверить, что побочный эффект вообще случился («audit-лог записан ровно один раз при сбое»), где взаимодействие и есть поведение. Для всего остального 20-строчный фейк, написанный однажды, бьёт сгенерированный мок, конфигурируемый в каждом тесте. Инъекция сбоев остаётся простой — добавьте поле failNextSave error и выставляйте его в тесте.

httptest: HTTP-граница без сети — или с ней

Для HTTP редко есть причина выдумывать дублёров: net/http/httptest поставляет два инструмента под два разных предмета тестирования. Тестируем хендлер: httptest.NewRecorder() плюс httptest.NewRequest() вызывают его как обычную функцию — без порта, без горутины, микросекунды на тест, — а ResponseRecorder захватывает статус, заголовки и тело для got/want-проверок. Тестируем клиента (логика ретраев, обработка таймаутов, auth-заголовки): httptest.NewServer(handler) поднимает настоящий листенер на 127.0.0.1, и продакшен-код с http.Client работает без изменений против URL, которым управляете вы; тестовый хендлер может вернуть дважды 503, затем 200, доказывая политику ретраев, или заснуть в time.Sleep дольше клиентского таймаута, доказывая срабатывание дедлайна. Правило выводится из предмета теста: рекордер — когда ваш код и есть сервер, настоящий сервер — когда ваш код разговаривает с сервером; рекордер не способен прогнать переиспользование соединений, таймауты или TLS (httptest.NewTLSServer — способен).

testcontainers честно — и провал пере-мокинга

Слою репозитория, чья логика и есть SQL, фейк не даёт ничего: фейкая хранилище, вы тестируете свою map, а не свой запрос. testcontainers-go поднимает настоящий Postgres в Docker — честно: это 1–3 с старта контейнера плюс pull образа на холодном CI, поэтому амортизируйте: один контейнер на пакет через TestMain, изоляция между тестами — транзакциями с откатом или схемой-на-тест, и держите сьют за testing.Short(), чтобы go test -short оставался субсекундным для внутреннего цикла. Выигрыш — что ON CONFLICT, нарушения ограничений и причуды изоляции тестируются против того движка, который их и исполнит; sqlmock-подобные драйверы, ассертящие SQL-строки, — худший вид моков: ломаются на пробелах, не валидируя ничего о семантике. Общий диагностический вопрос пере-мокинга один: если реализация изменилась, а поведение осталось тем же, пройдёт ли этот тест? Если каждый рефакторинг означает правку цепочек EXPECT — сьют ассертит, как код работает: он тестирует мок. Фейки, рекордеры и настоящие движки отвечают на вопрос «да».