Тестирование хендлеров: httptest и chi

В mux.go chi есть func (mx Mux) ServeHTTP(w, r) — тот же метод, что у http.Server требует от Handler. Отсюда весь подход: роутер можно подать не только в сервер, но и позвать руками из теста. Пакет httptest go даёт две половины запроса. httptest.NewRequest(method, target, body) возвращает входящую http.Request без сокета: Proto всегда HTTP/1.1, RemoteAddr подставлен «192.0.2.1:1234» — адрес из TEST-NET-1, зарезервированного RFC 5737 для документации, а на ошибку в аргументах NewRequest паникует — в тестах это удобнее, чем проверка err. httptest.NewRecorder() возвращает ResponseRecorder — http.ResponseWriter, который пишет статус, заголовки и тело в память, чтобы их прочитал тест. Тестирование chi сводится к связке: собрать роутер той же функцией, что и main, прогнать через него запрос и сверить записи рекордера. Middleware при этом отрабатывают все: стек оборачивает внутренний routeHTTP, и ServeHTTP — это уже готовая цепочка, а не голая маршрутизация.

Вторая половина пакета — httptest.NewServer(handler): он поднимает настоящий http.Server на 127.0.0.1 с портом :0, то есть случайным свободным, отдаёт ts.URL и настоящий клиент ts.Client(). По докстрингу Close блокируется, пока не завершатся все незавершённые запросы, — defer ts.Close() обязателен, иначе слушатели утекут между тестами. Что здесь появляется сверх ServeHTTP: реальный TCP и парсинг протокола net/http, keep-alive-соединения, поведение настоящего клиента — редиректы, cookies, таймауты, — а httptest.NewTLSServer добавляет TLS с сертификатом сервера. Это инструменты для тестов самого сервера и пути «клиент → сеть → стек»: healthz для балансировщика, интеграционный дым, проверка таймаутов http.Server. Цена — сокеты, порты, медленнее и больше поверхность для гонок. Практичный расклад: основные тесты — ServeHTTP с рекордером, пара NewServer на критический путь, где важен именно протокол, а не логика хендлера.

Первое правило: запрос — через роутер, а не напрямую в хендлер. Маршрут должен реально смэтчиться: chi.URLParam наполняется только роутером, при прямом вызове в контексте нет RouteContext, и параметр — пустая строка. Отсюда главная ценность таких тестов — они ловят опечатки в шаблонах: r.Get("/notes/{it}") против chi.URLParam(r, "id") даст пустой параметр на всех запросах, и тест через роутер упадёт сразу, а не на проде. Проверки по слоям: статус — rr.Code после явного WriteHeader либо rr.Result().StatusCode для неявных; тело — rr.Body.String() для текста, для JSON — json.Unmarshal в структуру и сравнение полей, строковое сравнение сериализованного JSON хрупко из-за порядка ключей; заголовки — rr.Header().Get, тот же Content-Type и будущий Allow. Отдельный слой — параметры маршрутов: тест должен доказать, что {id} из шаблона реально доехал до хендлера.

Через роутер проверяются и системные ответы, разобранные в уроке про централизованные ошибки. Несуществующий путь — 404: либо дефолтный «404 page not found» text/plain, либо ваш JSON из r.NotFound. Путь существует, метод не тот — 405: дефолтный хендлер chi v5.0.8 делает WriteHeader(405) и пустое тело, даже Allow не ставит; после подмены в r.MethodNotAllowed возвращается ваш формат со списком разрешённых методов. Тест фиксирует, какой из двух контрактов действует сейчас: обновление chi или чужой рефакторинг не должны менять ответ молча. Побочный бонус: опечатка в шаблоне проявляется как 404 — тот же тест, что проверяет позитивный сценарий, ловит и сломанный маршрут, если ожидаемый статус и тело прописаны явно, а не «что-нибудь да пришло».

Middleware из урока про собственные слои проверяется обёрткой над заглушкой: next-хендлер записывает факт «меня позвали» и не делает ничего. Заглушка-шпион — булево поле или счётчик в замыкании — отделяет два принципиально разных исхода: middleware ответил сам (заглушка не позвана) или пропустил дальше (позвана). По слоям проверяется всё, что middleware делает: выставленный статус, добавленный заголовок, значение в контексте после r.WithContext, короткое замыкание при отказе. Звать middleware можно напрямую — mw(next).ServeHTTP(rr, req): быстрее и точнее для юнита конкретного слоя; через собранный роутер — когда проверяется порядок слоёв, что Logger видит честный статус от errorHandler или что RequireAdmin стоит раньше хендлера. Напрямую — для поведения одного middleware, через роутер — для композиции; полноценно нужны оба уровня, и таблица ниже собирает их в один список.