Моки в Go через интерфейсы

Узкий интерфейс у потребителя

Зависимость принимают интерфейсом, который объявлен в пакете-потребителе и содержит ровно те методы, что вызываются. У меня это был интерфейс с одним методом Name(id int) (string, error) - и подделка к нему уместилась в структуру с полями name и err.

Дальше проверяются обе ветки за два вызова: с именем сервис вернул «привет, Аня», с ошибкой - «гость». Никакой базы, никакой сети, весь тест мгновенный.

// Генератор моков оправдан, когда интерфейс широкий и нужно проверять порядок и число вызовов. Для узкого контракта он добавляет сборочный шаг ради того, что пишется руками за минуту.

фейк

простая рабочая подделка зависимости

интерфейс у потребителя

контракт объявляет тот, кто вызывает

Однометодный контракт: замыкание вместо структуры

Если в интерфейсе один метод, структуру можно не заводить вообще. Объявляешь тип-функцию с нужной сигнатурой, вешаешь на неё этот метод - и дальше подставляешь обычное замыкание прямо в тесте.

Я так и проверил: подставил замыкание, которое возвращает «юзер-42», и сервис отдал «привет, юзер-42». Ровно этот приём стандартная библиотека использует в http.HandlerFunc, поэтому в чужом коде он читается без пояснений.

// Побочная выгода: каждый тест задаёт своё поведение прямо на месте, без полей структуры и без переключателей внутри подделки.

тип-функция

замыкание вместо структуры для одного метода

http.HandlerFunc

тот же приём в стандартной библиотеке

httptest: рекордер против настоящего сервера

Замерил оба варианта на обработчике, который спит 30 мс. Через httptest.NewRecorder обработчик вызывается напрямую как функция - 30 мс. Через httptest.NewServer поднимается настоящий сервер на свободном порту, у меня это был 127.0.0.1:44109, и запрос занял 32 мс.

То есть выигрыш рекордера не в скорости - две миллисекунды на петле разницы не делают. Он в том, что нет порта, нет второй горутины, нет уборки, а статус, заголовки и тело можно посмотреть прямо в структуре: 418, заголовок X-Trace, тело целиком.

// NewServer нужен, когда тестируешь клиента, а не обработчик. Я поставил клиенту таймаут 10 мс против ответа в 30 - получил ошибку, как и должно быть. Редиректы, повторы и таймаут рекордером не проверить, там нужен настоящий транспорт.

ResponseRecorder

запись ответа обработчика без сети и порта

httptest.NewServer

настоящий сервер: для тестов клиента

Как отвечать: «Как подменяете зависимости в тестах?»

Через интерфейс, объявленный в пакете-потребителе. Толстый контракт рядом с реализацией я не описываю, а перечисляю у потребителя ровно те методы, которые вызываю, обычно один-два. Тогда подделка в тесте выходит на три строки: структура с парой полей и метод, возвращающий заранее заданный результат. Обе ветки, успех и ошибка, проверяются двумя вызовами без базы и без сети. Генераторы моков беру редко, они оправданы на широком интерфейсе, где надо проверять порядок и число вызовов. Для однометодного контракта удобнее приём с типом-функцией: объявляешь тип с нужной сигнатурой, вешаешь на него метод и подставляешь обычное замыкание - ровно так сделан http.HandlerFunc в стандартной библиотеке. Для HTTP пользуюсь httptest. Рекордером, когда тестирую обработчик: он вызывается напрямую, а статус, заголовки и тело лежат в структуре. Настоящим сервером, когда тестирую клиента, потому что таймауты и редиректы иначе не проверить - я так и ловил ошибку на клиенте с таймаутом 10 миллисекунд против ответа в 30. А стык с базой моками не закрываю вовсе: мок не воспроизводит диалект SQL, поведение транзакций и ограничения целостности, поэтому там держу горстку интеграционных тестов на контейнере, а логику проверяю юнитами на подделках.

Сильный ответ: подход выведен из идиомы «интерфейс объявляет потребитель», объяснено, когда генератор всё-таки нужен, разведены два инструмента httptest по задачам и обозначена граница применимости моков. Последнее - признак человека, который ловил расхождения между моком и настоящей базой.

На чём валят

• −Объявляют толстый интерфейс рядом с реализацией, и подделки распухают до сотни строк.
• −Тянут генератор моков туда, где хватает трёх строк руками.
• −Тестируют обработчик через настоящий сервер, хотя достаточно рекордера.
• −Закрывают моками стык с базой и узнают про диалект SQL уже на проде.
• −Проверяют в тесте детали реализации вместо наблюдаемого поведения.