Тестирование Connect-сервисов

Начнём с самого дешёвого уровня. Ваш notesServer реализует сгенерированный интерфейс — значит, тест может создать его напрямую и вызвать метод как обычную функцию Go: собрать request-структуру, получить ответ и ошибку. Такой тест собирается за микросекунды, не требует http.Client, не зависит от protobuf-сериализации и идеально подходит для бизнес-логики: правил доступа, валидации, вычислений. Но у него есть жёсткая граница — внутри прямого вызова нет Connect. Ошибка, которую хендлер вернул через connect.NewError, в тесте — та же обычная Go-ошибка, что и любая другая: коды, статусы HTTP и сериализация на этом уровне не существуют. Это не баг, а свойство уровня: вы тестируете функцию, а не RPC. Отсюда правила гигиены. Первое: бизнес-ошибки возвращайте connect.NewError с осмысленным кодом уже в хендлере — тогда и прямой тест, и полный стек увидят одну и ту же семантику (как раскладывать ошибки по кодам — шестой урок). Второе: в прямых тестах проверяйте именно логику — ветки, границы, инварианты хранилища, — и не пытайтесь через них проверять заголовки, коды в HTTP и перехватчики: для этого есть следующий уровень. Третье: если хендлер тянет зависимости — хранилище, часы, генератор идентификаторов, — заведите их в тестовой версии фейками на простых структурах; интерфейсы из третьего урока этому помогают. Прямые тесты — это unit-уровень вашего RPC-приложения, и их должно быть большинство: они дешевле всего и падают точнее всех.

Главный приём httptest connect-разработки: поднять ваш настоящий хендлер через httptest.NewServer и вызвать его настоящим сгенерированным клиентом. Вы собираете mux ровно как в третьем уроке — path, handler из NewNoteServiceHandler, опции WithInterceptors, WithReadMaxBytes, всё честно, — отдаёте mux в httptest.NewServer и получаете listening-адрес. Клиенту NewNoteServiceClient нужен http.Client и базовый URL — и httptest даёт оба готовыми: server.Client() — уже настроенный клиент тестового сервера, server.URL — адрес. Всё это в памяти одного процесса: ни портов вручную, ни ожидания старта, ни сокетов в CI. Что такой тест проверяет на самом деле — весь протокольный путь: protobuf-сериализацию запроса и ответа, HTTP-маппинг кодов из шестого урока, перехватчики из седьмого, лимиты чтения и сжатие из четырнадцатого урока. Именно поэтому код ошибки здесь наконец проверяется честно: helper connect.CodeOf возвращает код connect-ошибки, и тест утверждает не текст, а семантику — CodeNotFound, CodeInvalidArgument, CodePermissionDenied. Стандартная форма — таблица кейсов с t.Run: на каждый код свой случай {запрос, ожидаемый код}, и один прогон покрывает всю матрицу ошибок. Замечание про URL: client подключается к server.URL, а не к отдельному адресу — и если в тестах нужен строгий базовый URL (например, для перехватчика, который смотрит на процедуру), он задаётся при сборке клиента, как в проде. Так появляются тесты connect-контракта: тот же код, что исполняется в проде, вызывается тем же клиентом, что едет в проде, — отличается только транспорт под ним.

Перехватчики — самый недооценённый предмет тестирования, и зря: именно в них живут сквозные ошибки — авторизация, логирование, лимиты. Перехватчик — обычное значение типа connect.Interceptor, значит его можно тестировать двумя способами. Первый — изолированно: WrapUnary получает вызов next и запрос; тест подставляет фейковый next, который записывает, что до него доехало, — и проверяет, что перехватчик добавил нужные заголовки, проставил значения в контекст или отклонил запрос. Второй — в составе полного стека: хендлер собирается с WithInterceptors(authInterceptor из тринадцатого урока), и тестовые вызовы либо несут токен в req.Header(), либо нет. Второй способ честнее, потому что проверяет то, как перехватчик реально смонтирован, — и это тест на несколько строк: вызов без заголовка Authorization должен вернуть CodeUnauthenticated, вызов с протухшим токеном — тоже, вызов с валидным — пройти до хендлера. Отдельный инструмент для мелких проверок — тестовый перехватчик, который вешается на клиент в полном стеке и подглядывает за запросами и ответами: им удобно фиксировать, что сервер проставил заголовки ответа или что процедура вызова выглядит как /notes.v1.NoteService/GetNote. Контекстные значения из тринадцатого урока — userFromContext — проверяются там же: перехватчик кладёт пользователя в контекст, хендлер его читает, тест проходит только если связка работает в настоящем потоке исполнения. Практический минимум для auth-контура: три кейса полного стека (нет токена, плохой токен, хороший токен) — и у вас есть исполняемая документация безопасности, которая падает раньше, чем упадёт прод.

Стримы из восьмого урока тестируются на том же httptest — генерированные стрим-клиенты работают против тестового сервера без изменений, и здесь появляются две новые вещи: порядок сообщений и завершение потоков. Для server-streaming тест сводится к циклу Receive: клиент открывает поток, читает ответы до io.EOF и сравнивает полученную ленту с ожидаемой — проверяется и содержимое, и порядок, и что сервер закрыл поток корректно. Для client-streaming — обратная картина: тест шлёт сообщения через Send и закрывает отправку, сервер отвечает одним итогом; проверяется, что ничего не потерялось между сообщениями. Для bidi, где обе стороны говорят одновременно, тестам полезен helper CloseAndReceive у клиентского потока: он закрывает отправку и дочитывает все ответы — в тесте это снимает гонку «кто первый закрылся». И главная ловушка стрим-тестов — горутины: серверный хендлер стрима исполняется в отдельной горутине, поэтому флаг -race при тестах обязателен, а общий стейт между хендлером и тестом защищайте каналами или мьютексом, как в любом конкурентном Go. Второй класс проверок на стримах — отказы посреди потока: сервер возвращает ошибку после трёх сообщений, и тест должен увидеть три успешных Receive, затем ошибку с ожидаемым кодом — именно так ведут себя лимиты и таймауты на длинных потоках. Третий класс — большие сообщения: стрим с сообщением больше WithReadMaxBytes из четырнадцатого урока должен отвалиться ресурсным кодом, и полный стек это подтвердит без единого реального сокета. Стрим-тесты медленнее unary, но на httptest всё ещё миллисекунды — их можно гонять в каждом PR, а не только ночью.

Полный стек на httptest не проверяет ровно одно — окружение: настоящую базу данных, миграции, соседние сервисы, конфигурацию. За это отвечает интеграционный уровень, и первый его инструмент — разделение через build-теги: медленные тесты с реальными зависимостями помечаются //go:build integration и не бегут в быстрой петле go test ./...; в CI их включает отдельный шаг. Внутри интеграционного теста картина та же, что и на httptest, — сервер, клиент, CodeOf, — только зависимости настоящие: тестовая база поднимается контейнером (инструменты вроде testcontainers это автоматизируют), миграции прогоняются до тестов, данные между кейсами изолируются. Второй момент — протокольное покрытие: сгенерированный клиент по умолчанию говорит протоколом Connect; убедиться, что хендлеры совместимы и с gRPC-клиентами, позволяют отдельные интеграционные проверки gRPC-инструментами — например, grpcurl-ом против поднятого сервиса, что заодно проверяет рефлексию из пятнадцатого урока. Третий момент — гонки и утечки: go test -race обязателен для всего курса тестов, а для стрим-хендлеров добавьте проверку, что горутина завершается после закрытия потока (pprof-счётчик горутин в тесте — грубый, но действенный приём). Четвёртый — конвейер: CI из одиннадцатого урока уже гоняет buf lint, buf breaking и buf generate с git diff --exit-code; тестирование connect вписывается туда же строками go test -race ./... для быстрого контура и go test -tags integration ./... для интеграционного. И последнее — экономика: прямой вызов стоит микросекунды, полный стек — миллисекунды, интеграция — секунды; распределяйте кейсы по слоям так, чтобы каждый тест падал там, где возникла причина, а не уровнем выше.

Тестовый контур собран: логика — прямыми вызовами, контракт — полным стеком на httptest, окружение — интеграцией за build-тегом. Дальше по курсу: семнадцатый урок — метрики и наблюдаемость, где тестированный сервис получит счётчики и латентности; двадцать второй — деплой, где интеграционный контур встретится с настоящим ingress. Для повторения: коды ошибок — в шестом уроке, перехватчики — в седьмом, защита и лимиты — в тринадцатом и четырнадцатом, рефлексия и доки — в пятнадцатом. Программа всех двадцати пяти уроков — на странице курса.