Тестирование endpoints

У go-сервиса четыре тестируемых этажа, и скорость теста обратно пропорциональна его ценности в рантайме: чем выше этаж, тем реже и дороже его проверяют. В основании — сервис: table-driven тесты StringService из урока 03, микросекунды на прогон, десятки кейсов на метод. Второй этаж — endpoint'ы: те же table-driven, но вызывается makeUppercaseEndpoint, и проверяется шов адаптера: type assertion, маппинг ошибок в Err-поле, Failer. Третий — обёртки обоих этажей из уроков 14 и 15: endpoint-middleware проверяются с fake-next, декораторы — с fake-сервисом; изоляция полная, никакого транспорта. Четвёртый — транспорт и кодеки: kithttp.NewServer гоняется на httptest.NewRecorder без сети, интеграционный сценарий — на httptest.NewServer с реальным HTTP-циклом. Тестирование go kit дорожает по этажам: сервис — миллисекунды, endpoint — миллисекунды, middleware — единицы миллисекунд, транспорт — десятки. Держи пропорцию пирамиды: много быстрых тестов внизу, горстка интеграционных наверху; end-to-end прогон с curl оставь деплою. Ключ к этажу — простая мысль: в go-kit почти всё — функции, а функции тестируются вызовом.

Начни с главного приёма курса. Endpoint — сигнатура func(ctx, request) (response, error) — зовётся в тесте напрямую: ep := makeUppercaseEndpoint(svc); resp, err := ep(context.Background(), UppercaseRequest{S: "go"}). Никакого декодера, никакого HTTP: таблица кейсов с входной строкой, ожидаемым V и ожидаемой ошибкой — почти копия table-driven теста сервиса из урока 03, только проверяется ещё и адаптер. Что здесь проверяется, а что нет. Проверяется: assertion request-структуры, вызов метода сервиса, упаковка ответа, перенос ErrEmpty в Err-поле через Failer — весь шов из урока 02. Не проверяется: JSON, статусы, заголовки — это транспорт, его тест ниже. Вторая причина endpoint тестов — обёртки: makeUppercaseEndpoint(svc) принимает декорированный сервис, поэтому один и тот же тест можно прогнать на чистом сервисе и на матрёшке с кэшем из урока 15 — и это уже тест интеграции этажей, всё ещё без сети. Ошибки в тестах проверяются через errors.Is на sentinel: строковое сравнение err.Error() ломается при первой же обёртке fmt.Errorf с %w из урока 14.

Endpoint-middleware тестируется подстановкой next: обёртка — функция над функцией, значит в тест next ставится стаб, поведение которого ты контролируешь полностью. Два шаблона. Первый — сигнальный next: стаб-функция ставит флаг «меня вызвали» или паникует по требованию — им проверяется, что лимитер не пропустил вызов, что timeout отменил контекст, что recovery превратил панику в ошибку. Второй — записывающий next: стаб фиксирует контекст и аргументы, им проверяются обёртки-трансформеры вроде errwrap из урока 14. Отдельная прелесть — логгер-стаб: реализация log.Logger из урока 06 — один метод Log(keyvals ...interface{}) error; двадцать строк собирают логгер, который копит пары в срез под мьютексом, и middleware логирования можно проверять дословно. Мокается только next и зависимости, потому что именно они интерфейсы; сами endpoint middleware — конкретные функции, и тестируются как функции. Так и работает тестирование go kit: мокать то, что твоя обёртка вызывает, а не то, что она есть.

Service-middleware из урока 15 тестируется зеркально: вместо fake-next — fake-сервис, реализующий StringService. Стаб-реализация считает вызовы метода (атомарный счётчик или канал-лог), возвращает заранее заготовленные ответы и умеет ломаться по сценарию — вернуть ErrEmpty, зависнуть на канале. Классический кейс кэша: fake-сервис, поверх которого cachingMiddleware; первый вызов инкрементирует счётчик base, второй — нет, при этом оба вернули одно значение, а sentinel-ошибка не закэшировалась. Это тест целого контракта из урока 15 — три утверждения из одной таблицы. Заметка об интеграции этажей: матрёшку для теста собирай той же applyMiddleware, что и prod-код — если тест соберёт декораторы руками, а main через срез, расхождение однажды проскочит мимо тестов. И ещё: fake-сервис — это не «мок-библиотека»: для интерфейса из двух методов ручной стаб дешевле и нагляднее кодогенерации; gomock и компания уместны, когда интерфейсов десятки и обновлять стабы руками дороже, чем держать тулчейн.

Транспортный этаж проверяется двумя уровнями, и первый — без сети вообще. kithttp.NewServer возвращает http.Handler, а httptest.NewRecorder — фейковый ResponseWriter, который собирает статус и тело в память. Собери сервер, сформируй httptest.NewRequest, вызови server.ServeHTTP(w, r) — и весь HTTP-цикл прошёл, не открыв ни порта. Что здесь проверяется: декодер (сломанный JSON должен дать честный 400 из урока 05), энкодер (Content-Type application/json), error encoder (ErrEmpty → 400 с телом {"error":"empty string"}, кривая ошибка → 500), Failer-контракт. Мутации канона: этот тест — единственное место, где транспортные типы легальны в тесте; всё остальное про байты живёт в кодеках. Скорость — микросекунды на кейс, поэтому транспортная таблица может быть такой же жирной, как сервисная. Второй уровень — интеграция: httptest.NewServer поднимает настоящий listener на loopback; его цена — десятки миллисекунд, его ценность — проверка полного цикла: json.Marshal, заголовки, конверт ошибки, поведение клиента. Один-два таких теста на сервис достаточно.

Второй уровень транспортных тестов поднимает настоящий HTTP-сервер: httptest.NewServer(server) слушает loopback и отдаёт базовый URL; тест идёт обычным http.Client — как реальный потребитель. Ценность уровня: он проверяет стыки, которые Recorder не видит — сериализацию json.Marshal в энкодере, заголовки Content-Type обеих сторон, обработку редиректов и таймаутов клиентом, а главное — форму конверта ошибки глазами клиента: тест декодирует ответ в структуру и сверяет поле error, а не substring тела. Дедлайн теста — context.WithTimeout на запрос: зависший сервер не повесит CI, а упадёт с понятным сообщением за две секунды. Заметь честную деталь: этот тест ходит по сети — localhost, но сеть; он медленнее и чуть более хрупкий, поэтому его в одном экземпляре на критичный метод, а не на каждый кейс таблицы. Мок-транспорт, о котором спрашивают чаще всего, — это и есть httptest.NewServer: go-kit не требует мокать kithttp — сервер готов, а мокаешь ты свой сервис под ним.

Обратная сторона пирамиды — куда тесты не нужны. Не тестируй go-kit: kithttp.NewServer гарантированно вызывает endpoint, это покрыто библиотечными тестами; твой Recorder-тест уже проверяет интеграцию с твоими кодеками — дублировать внутренности пакета бессмысленно. Не тестируй обёртки других людей в их же терминах: gobreaker проверял свои состояния, твоя зона ответственности — контракт ErrOpenState → 503 в твоём encodeError. Не пиши тесты на конфигурацию в main: сборку матрёшек проверяют типы компилятора и один интеграционный тест. И не гоняйся за процентом покрытия в тестах каркаса — гони гонку и детерминизм: go test -race -count=1 в CI обязателен для всего, что касается middleware из уроков 14-15, потому что замыкания исполняются параллельными горутинами, а мьютексы и атомарные счётчики проверяются только рантаймом с гонкой. Правило выбора цели теста простое: тестируй то, что написал ты, через контракт, который объявил ты, — библиотека остаётся чёрным ящиком, твой код — белым. Финальная строка CI-конфига: go-kit тесты гоняются с -race -count=1 — привычка, которая окупается с первого инцидента.

Тесты, проверяющие время, — главный источник flakiness, и у go-kit-стека есть аккуратный выход. Не пиши time.Sleep в тестах: Sleep(100ms) на быстрой машине стреляет в 99% прогонов, а на CI в час пик — в 95%, и красные тесты перестают что-либо значить. Вместо этого сжимай время: timeout-обёртка из урока 14 тестируется с дедлайном в пять миллисекунд против fake-next, который блокируется на канале без записи; TestRecovery паникует мгновенно; retry-декоратор из урока 15 конфигурируется паузой в наносекунды — зависимость паузы приходит конструктором, как и всякая другая. Если тест должен дождаться события — дождись его блокирующим чтением канала, а не опросом со сном: стаб может отдавать chan struct{}, тест читает с context.WithTimeout. Дедлайн теста — всегда: t.Deadline или контекст на запрос; упавший тест лучше зависшего. И помни про -race: обёртки, кэши и логгер-стабы — многогорутинный код, гонка в тесте — баг в проде, который успел проголосовать.

Тестовая пирамида stringsvc стоит на всех четырёх этажах: сервис и endpoint — table-driven, обёртки — на стабах, транспорт — на httptest. Всё, что написано в уроках 02-15, теперь проверяемо изоляционно, и это последний аргумент в пользу слоистой архитектуры из урока 01-filosofiya: слой тестируется по контракту соседа, а не по контракту мира. Дальше карта курса ведёт в стройку: урок 17-struktura — структура go kit проекта (каталоги, DI, шаблон большого сервиса), затем конфигурация и graceful shutdown; обе темы опираются на матрёшку и endpoint-цепочку из уроков 14-15, которые ты теперь умеешь и писать, и тестировать. Путь до итогового проекта урока 25 — на странице курса; HTTP-декодер для тестов освежи в уроке 04-http-transport.