Тестирование Fiber-приложений

Финальный блок двадцатого урока обещал тестам ровно три вещи, и сегодня мы исполним все три. Первая: фабрика configFromEnv просится под тесты — t.Setenv подставляет переменную окружения, app.Test прогоняет запрос через приложение без сети, и вы проверяете, что мусорное значение действительно оставило дефолт Fiber, а не тихо сломало конфиг. Вторая: у app.Test есть TestConfig с полем Timeout и управлением FailOnTimeout — таймауты, которые мы выбирали для сервера в масштабе процесса, возвращаются в масштабе отдельного теста: миллисекунды вместо секунд uptime, и провал вместо зависания. Третья: graceful shutdown тоже тестируется — медленный хендлер, дедлайн и наблюдение, что ответ уехал целиком, — это обычный тест без systemd и docker stop.

Почему это отдельный урок, а не приложение к конфигурации: тестирование fiber меняет саму точку зрения на код, который мы писали двадцать уроков. Хендлер перестаёт быть функцией, которую проверяют curl-ом на живом сервере, и становится функцией, чьё поведение зафиксировано тестом; middleware из седьмого урока — не строкой в app.Use, а контрактом «401 без ключа, 200 с ключом»; ErrorHandler из четырнадцатого — не «настройкой формата», а обещанием статуса, Content-Type и тела, которое нарушается только осознанно. Дальше по уроку: механика app.Test без сети, сигнатура по буквам, TestConfig и дедлайны, httptest.NewRequest и httptest.NewRecorder на фоне стандартной библиотеки, юнит-тесты хендлеров, table-driven тесты стража requireAPIKey, тесты ErrorHandler, словарь ошибок тестовой обвязки, t.Setenv для фабрики конфига и graceful-инвариант под тестом.

Метод app.Test объявлен в app.go ядра fiber v3.5.0, и его док-комментарий скромен до обмана: Test is used for internal debugging by passing a *http.Request. Config is optional and defaults to a 1s error on timeout, 0 timeout will disable it completely. «Для внутренней отладки» — единственная официальная роль; на практике же это главный способ тестирования fiber-приложений, и лучший тому свидетель — сами исходники: в файле app_test.go вызов app.Test встречается сто семьдесят раз. Ни один из этих тестов не поднимает настоящий слушатель: весь корпус проверок фреймворка — от маршрутизации до ErrorHandler и graceful-таймаутов — гоняется через один метод, которому не нужны ни сеть, ни порт, ни время на рукопожатие.

Как это работает, шаг за шагом. Сначала app.Test сериализует запрос целиком через httputil.DumpRequest(req, true): метод, путь, заголовки, тело — всё уходит в сырые байты, как будто их написал настоящий клиент. Затем создаётся testConn — тип из helpers.go, реализующий интерфейс net.Conn поверх пары bytes.Buffer: то, что вы пишете, читает сервер; то, что он пишет, читаете вы; между ними нет ни TCP, ни сокета — только два буфера в памяти. Подготовленный коннект подаётся в горутине на app.server.ServeConn(conn) — тот самый fasthttp-сервер, который обслуживал бы живое TCP-соединение, кормится коннектом из памяти. Ответ собирается обратно функцией httpReadResponse в настоящую *http.Response, а цикл чтения аккуратно отбрасывает промежуточные ответы 1xx — например, Early Hints — и возвращает первый со статусом 200 и выше.

Отсюда три следствия, которые определяют весь урок. Первое: тестам не нужен порт — канон :8080 остаётся делом Listen из двадцатого урока, а не дела тестового. Второе: тестируется полный стек — middleware в порядке app.Use, роутер, хендлер, ErrorHandler; app.Test не умеет «дёрнуть один хендлер в отрыве», и это достоинство, как мы увидим в блоке про юнит-тесты. Третье: время в тесте реальное — хендлер с time.Sleep спит по-настоящему, поэтому у TestConfig существует дедлайн, о котором говорит следующий после канона блок.

И последнее — о скромности док-комментария: он называет app.Test инструментом внутреннего дебага, а в app_test.go сто семьдесят вызовов — fiber тестирует им сам себя. Переведите и на свой код: это не обходной путь «до настоящих тестов», а штатный, верифицированный всем корпусом тестов фреймворка способ тестирования fiber-приложений.

Сигнатура целиком: func (app App) Test(req http.Request, config ...TestConfig) (http.Response, error). Разберём по позициям, потому что каждая несёт смысл. Аргумент — http.Request из net/http: не fiber.Ctx, не строка, не самодельный DTO; это тот же тип, что строит httptest.NewRequest, и тот же, что получает хендлер обычного net/http-сервера. Любое знакомство с httptest из гайдов по стандартной библиотеке переносится сюда без поправок — и наоборот, тесты этого урока научат вас httptest-у, который пригодится и вне Fiber.

Конфиг — вариадик: config ...TestConfig. Внутри метода берётся только первый элемент, поэтому передавать два конфига бессмысленно; вариадик существует ради красоты вызова — app.Test(req) без третьей строки. Дефолт формируется в теле: cfg := TestConfig{Timeout: time.Second, FailOnTimeout: true}, и только если конфиг передан — он замещает дефолт целиком: полей «слить с дефолтом по одному» нет, если указали Timeout и промолчали про FailOnTimeout, флаг будет false, а не true. Это частая ловушка, и мы вернёмся к ней в блоке про TestConfig.

Возвращаемое значение — (*http.Response, error), и это самое важное дизайн-решение метода. Вы получаете ответ стандартной библиотеки: StatusCode, Header, Body, Cookies. Не fiber.Ctx — контекст Fiber не переживает запрос, он переиспользуется пулом и наружу не отдаётся. Не число и не строка. Все проверки теста — обычная работа с net/http: resp.StatusCode, resp.Header.Get("Content-Type"), io.ReadAll(resp.Body), json.Unmarshal для конверта items.

Перед подачей в сервер Test доводит запрос до ума тремя штрихами, и каждый — защита от забывчивости. Если тело не пустое и заголовок Content-Length не задан, значение дописывается само из req.ContentLength — иначе fasthttp не понял бы, сколько байт читать. Если Host пуст, он берётся из req.URL.Host, а при пустом URL — «localhost»: дамп запроса обязан содержать Host, иначе сервер вернёт ошибку. Наконец, RequestURI обнуляется, чтобы DumpRequest написал origin-form строку запроса «GET /api/tasks HTTP/1.1» вместо абсолютной формы с URI. Для вас это значит: httptest.NewRequest("GET", "/api/tasks", nil) достаточно — остальное тестовая обвязка сделает сама, и в объяснениях ошибок теста не будет ни одного «missing Host».

TestConfig — структура ровно с двумя полями, и оба стоит выучить дословно, потому что док-комментарии в app.go формулируют их контракт без воды. Первое поле — Timeout time.Duration: defines the maximum duration a test can run before timing out, Default: time.Second. Это максимум, который тест готов ждать ответа; по умолчанию — одна секунда. Второе поле — FailOnTimeout bool: specifies whether the test should return a timeout error if the HTTP response exceeds the Timeout duration, Default: true. Это решение о том, что делать, когда дедлайн истёк: по умолчанию — вернуть ошибку и провалить тест.

Механика внутри app.go прозрачная. Горутина с ServeConn пишет итог в буферизованный канал; тестовый поток стоит в select между этим каналом и time.After(cfg.Timeout). Пришёл ответ — он возвращается; истёк дедлайн — развилка FailOnTimeout. При true соединение закрывается, и возвращается ошибка, совместимая с os.ErrDeadlineExceeded, — тест красный, и это правильный исход: хендлер, который не успевает за дедлайн, нарушает контракт производительности, и пусть об этом говорит тест, а не пользователь в пятницу вечером. При false — поведение тоньше, и оно зафиксировано в исходнике дословно: When FailOnTimeout is false, wait up to 1 additional second for the handler to complete and write a response — тест даёт хендлеру ещё одну секунду дописать ответ и возвращает то, что успел; тест остаётся зелёным, если ответ доехал в этом дополнительном окне. Ноль в Timeout — третий режим: ожидание без ограничения, select без ветки time.After; тот самый 0 timeout will disable it completely из док-комментария.

Почему дедлайн — необходимость, а не украшение: go test убивает пакет по общему таймауту, и один зависший тест подвешивает всю сессию CI без внятного отчёта. TestConfig — предохранитель точечный: красный тест с ошибкой дедлайна точно говорит, какой хендлер и какой сценарий зависли. Отсюда правило выбора значений: дефолтной секунды хватает юнит-тестам — хендлеры без сети и базы отвечают за миллисекунды; Timeout поднимайте осознанно под реально медленные сценарии (сон, таймер из седьмого урока), а FailOnTimeout: false берите только когда тестируете сам факт «хендлер в итоге отвечает», а не его скорость.

Пакет net/http/httptest — стандартный ящик с инструментами для HTTP-тестов, и в нём два героя. Первый — httptest.NewRequest(method, target, body): строит полноценный *http.Request. Метод — строка ("GET", "POST"), цель — путь с запросом, тело — nil, http.NoBody или любой io.Reader: bytes.NewBufferString для JSON-тела, strings.NewReader для форм. Второй герой — httptest.NewRecorder: заглушка http.ResponseWriter, в которую хендлер пишет ответ; после вызова handler.ServeHTTP(rec, req) вы читаете rec.Code и rec.Body. Классический юнит-тест net/http выглядит так: NewRequest, затем ServeHTTP, затем проверки на recorder — и большинство гайдов по тестированию HTTP в Go описывает именно этот рисунок.

В Fiber этот рисунок ломается ровно в одном месте: у приложения нет метода ServeHTTP. Сервер Fiber — fasthttp, а не net/http: другой интерфейс, другой конвейер, и ResponseRecorder подсунуть некуда — несовместимость подписей, а не «пока не добавили». Но не спешите тащить сторонний тестовый фреймворк: app.Test закрывает ту же потребность, сохранив половину классической пары. httptest.NewRequest остаётся — он из стандартной библиотеки и работает как есть; вместо связки «recorder + ServeHTTP» становится app.Test, и это даже выгоднее. Recorder вернул бы вам result.Code и result.Body — числа и буфер, а app.Test возвращает настоящую *http.Response: с Header, Cookies и тем же io.ReadAll, каким вы читаете ответ живого клиента. Один и тот же тестовый код объединяет оба мира: запрос — от httptest, ответ — от net/http, а между ними Fiber прогоняет полный стек без сети.

Для полноты честности: NewRecorder в уроке остался не для красоты. Если у вас есть чистая функция-обработчик без Fiber, работающая с http.ResponseWriter, — тестируйте её рескардером, это правильный инструмент. Но как только код завязан на fiber.Ctx, путь один: buildApp и app.Test.

Требование «unit-тесты хендлеров» распадается на два вопроса: что считать юнитом и что проверять. Хендлер Fiber — функция func(c fiber.Ctx) error, и у соблазна вызвать её напрямую с фейковым Ctx ноги растут именно отсюда. Путь этот тупиковый: интерфейс Ctx широченный, самодельная заглушка либо реализует полсотни методов впустую, либо ломается при первом обновлении fiber, когда реальный код хендлера тронет метод, которого в заглушке нет. Правильный юнит для HTTP-хендлера — полный стек: buildApp, app.Test, ответ. Дешевизна та же — миллисекунды и ноль сети, — а покрытие честное: тестируются и роутер (правильный ли путь и метод), и middleware (страж впустил или нет), и сериализация (JSON-теги живее всех живых).

Первый структурный шаг — фабрика buildApp() из канона выше. Почему фабрика, а не глобальная переменная app: main вызывает её один раз, каждый тест получает свежий экземпляр; никаких общих Locals между тестами, никаких t.Cleanup с остановкой слушателя — потому что и слушать нечего. Свежее приложение на тест — это ещё и независимость сценариев: тест стража не зависит от того, что тест сериализации повесил на тот же путь другой middleware. Параллельность — t.Parallel из урока о тестировании в Go курса go-advanced — безопасна именно потому, что у каждого теста свой app и свой testConn.

Что проверять: статус, заголовки, тело — в порядке убывания стабильности. Статус — это контракт маршрута: 200 для /api/tasks с ключом, 401 без. Заголовки: Content-Type application/json после c.JSON, X-Request-ID, если requestid в стеке. Тело: io.ReadAll и json.Unmarshal в ту же структуру Task с тегами json:"id" и json:"title" — тест становится исполняемым контрактом формата items, и переименование поля в хендлере красит тест раньше, чем фронтенд в проде. Для POST то же самое с телом: httptest.NewRequest(fiber.MethodPost, "/api/tasks", bytes.NewBufferString("{\"title\":\"новая задача\"}")) и req.Header.Set("Content-Type", "application/json") — Fiber не угадывает формат тела, Content-Length допишется сам, а Content-Type — ваша забота.

Седьмой урок научил писать middleware — фабрику requireAPIKey(key) fiber.Handler, таймер вокруг c.Next(), передачу пользователя через c.Locals. Теперь научимся доказывать тестами, что слой делает ровно то, что обещал. Главный принцип: middleware тестируется как черный ящик через полный стек. Нельзя «вызвать слой напрямую» — для вызова нужен живой fiber.Ctx, а честно построить его вне приложения нельзя: контекст создаётся сервером на каждый запрос и требует внутренностей app. Самодельные заглушки Ctx — вчерашняя заглушка против сегодняшнего fiber. Черный ящик проще и сильнее: buildApp регистрирует слой ровно так, как main, app.Test подаёт запрос, и тест проверяет наблюдаемые последствия.

Для стража наблюдаемые последствия мы уже зафиксировали: 401 с JSON-телом {"error":"неверный API-ключ"} без верного ключа, 200 дальше по цепочке с верным. Три сценария в table-driven — и requireAPIKey покрыт лучше, чем curl-ом за неделю. Но у слоя седьмого урока есть и вторая половина контракта: c.Locals("user", "api-client"). Как проверить её? Приём называется хендлер-канарейка: в тестовом приложении под стражем вешается временный хендлер, который читает Locals и отдаёт значение в ответе; тест сверяет тело. Канарейка — единственный честный способ увидеть внутренности цепочки снаружи.

Таймер из седьмого урока проверяется по тем же правилам, но с оговоркой про флаки: строгие пороги «latency < 10ms» в тестах — генератор нестабильных провалов на перегруженном CI. Проверяйте инварианты, а не скорость: что значение записано, что оно положительное, что порядок слоёв не потерял ошибки (таймер в error-стиле обязан вернуть err из c.Next() как есть). И ещё одна вещь, которую тесты middleware дают бесплатно: порядок app.Use в buildApp идентичен порядку в main — если тесты собирают цепочку одной фабрикой с сервером, расхождение «в тесте страж был, в проде забыли» невозможно по построению.

Четырнадцатый урок собрал ErrorHandler как единый формат ошибок: поле fiber.Config{ErrorHandler: ...}, тип-алиас func(Ctx, error) error, лестница распознавания — errors.As на *fiber.Error для framework-овых отказов, errors.Is на доменные sentinel-ы, единый JSON-конверт {error, code} для API. Всё это — контракт с клиентом, а контракт, который не проверяется тестом, — это комментарий. app.Test превращает ErrorHandler из настройки в проверяемое поведение: собрать приложение с вашим ErrorHandler, повесить хендлер, возвращающий нужную ошибку, подать запрос — и сверить три вещи: статус, Content-Type и тело.

Каждая ветка лестницы — отдельный сценарий, и table-driven отсюда напрашивается. Сценарий первый: хендлер вернул fiber.NewError(fiber.StatusNotFound, "задача не найдена") — ожидание: статус 404, application/json, тело содержит текст и код 404. Сценарий второй: обычная errors.New("база недоступна") — ожидание: 500 (обычная ошибка не несёт статус), JSON с этим текстом: ваш ErrorHandler, в отличие от DefaultErrorHandler, отвечает JSON-ом, и тест фиксирует именно это отличие от дефолта четырнадцатого урока. Сценарий третий: обёртка fmt.Errorf("получить задачу: %w", fiber.ErrNotFound) — ожидание: 404, потому что errors.As/Is проворачивают цепочку Unwrap и находят *fiber.Error внутри. Сценарий четвёртый, для продвинутых: доменная ошибка ValidationError с полем Field — ожидание: 400 и имя поля в теле.

Отдельно стоит сказать про Content-Type. Дефолтный DefaultErrorHandler четырнадцатого урока отвечал text/plain; charset=utf-8 — и тест, проверяющий application/json, поймает регрессию, в которой кто-то вернул дефолт или написал ответ SendString-ом мимо формата. А страховка роутера — голый SendStatus(500), когда сам ErrorHandler упал, — тестируется сценарием с намеренно сломанным обработчиком: приложение с ErrorHandler, который возвращает ошибку, обязано отдать пустой 500. Это редкий, но самый ценный тест: он проверяет деградацию, а не идеальный путь.

app.Test возвращает ошибку не только по дедлайну — у тестовой обвязки собственный словарь, и все слова стоит выучить до первого провала в CI. Первая ошибка — ErrTestGotEmptyResponse с текстом test: got empty response. Она объявлена в app.go рядом с TestConfig как var ErrTestGotEmptyResponse = errors.New(...) и возникает, когда httpReadResponse упирается в io.ErrUnexpectedEOF: сервер не написал ни байта ответа, буфер коннекта пуст. Типичный источник — c.Drop(): хендлер осознанно рвёт соединение без статуса и тела. Другие источники — хендлер, который вернулся, ничего не записав, или обрыв по дедлайну ровно между запросом и первым байтом ответа. Проверяется через errors.Is: require.ErrorIs(err, fiber.ErrTestGotEmptyResponse). У этого факта есть дисциплинирующая сторона: тест, в котором хендлер Drop-ает, обязан ожидать пустой ответ явно — тихий Drop в тесте, ожидающем 200, станет красным тестом, а не молчаливой зелёной фикцией.

Вторая ошибка — ErrHandlerExited с текстом runtime.Goexit() called in handler or server panic; комментарий в error.go поясняет: returned by App.Test if a handler panics or calls runtime.Goexit(). Механика: горутина, обслуживающая коннект, обёрнута в defer, который проверяет, вернулась ли ServeConn в канал; если горутина ушла через панику или Goexit — в канал уходит ErrHandlerExited. Практическое следствие двойное. Хорошее: паника в хендлере без recover-middleware не валит go test с трассировкой стека всего прогона — она превращается в ошибку конкретного теста, который можно читать и чинить. Неудобное: привычного panic-стека в выводе вы не увидите, поэтому recover-middleware из шестого урока — первый слой в цепочке — остаётся обязательным: с ним паника превращается в 500 через DefaultPanicHandler, и ErrorHandler получает её уже как ошибку, которую тест может проверить по формату.

Мелочь напоследок: fmt.Errorf-обёртка failed to dump request: %w возвращается, если запрос невозможно сериализовать — например, тело из reader, который читается с ошибкой. Внутренняя errTestConnClosed с текстом testConn is closed остаётся деталью механики: Write в закрытый testConn возвращает её, и app.Test трактует это как штатный финал. Таблица ниже — справочник для быстрого чтения отчёта CI.

Фабрика configFromEnv из двадцатого урока была подарком с отложенным сроком: «фабрику легко покрыть тестами, подавая env через t.Setenv». Срок наступил. Пакет testing даёт t.Setenv(name, value): метод ставит переменную окружения и гарантированно возвращает всё, как было, после конца теста — включая случаи паники и t.Fatal; внутренние механизмы вроде os.Setenv сами по себе такой гарантии не дают, и это первая причина использовать именно t.Setenv. Вторая причина — честность параллельности: t.Setenv помечает тест как несовместимый с t.Parallel, и это правильно — окружение процесса глобально, два параллельных теста, спорящие за одну переменную, — гонка по определению.

Что проверять у фабрики: два фильтра, ради которых она писалась. Корректное значение «5s» в FIBER_READ_TIMEOUT должно превратиться в 5 time.Second — это ветка time.ParseDuration с err == nil. Мусорное значение «очень много» в FIBER_BODY_LIMIT обязано оставить дефолт 4 1024 * 1024 — это ветка, где strconv.Atoi вернул ошибку и двойной фильтр err == nil && n > 0 отработал. Отдельный сценарий — пустая переменная: фабрика обязана вести себя так же, как при её отсутствии. И финальный штрих интеграции: приложение целиком — fiber.New(configFromEnv()), один запрос через app.Test — доказывает, что мусорное окружение не роняет старт и /api/tasks отвечает с дефолтами; это ровно тот тест, который тизер прошлого урока обещал дословно.

Цена вопроса: конфигурация, которую нельзя проверить тестом, — надежда. Фабрика из двадцати строк с двумя фильтрами после такого теста становится документированным контрактом: любое изменение правила парсинга сначала красит тест, потом едет в релиз.

Тизер прошлого урока обещал: graceful shutdown тоже тестируется. Честная формулировка границы: app.Test — про путь запроса, а не про остановку процесса. Слушатель и обработчик сигналов из двадцатого урока живут в Listen и в горутине остановки — их полный цикл тестируется интеграционно, локальным kill -TERM с curl в фоне, как в двадцатом уроке. Но инвариант graceful — «медленный запрос успевает дописать ответ, пока его не оборвали» — проверяется в миниатюре прямо здесь: хендлер с time.Sleep, TestConfig с Timeout больше сна, и зелёный тест подтверждает, что ответ уезжает целиком. Сожмите дедлайн ниже сна — получите провал по os.ErrDeadlineExceeded. Дедлайн, который в проде задаёт ShutdownWithTimeout, в тесте задаёт TestConfig — та же арифметика «запас должен быть больше самого медленного легитимного запроса», только в миллисекундах и на каждый прогон.

В исходниках fiber есть готовые образцы. Test_Test_Timeout в app_test.go — хендлер со Sleep 200 миллисекунд, TestConfig{Timeout: 20 * time.Millisecond, FailOnTimeout: true} и require.Error: дедлайн короче хендлера — тест обязан упасть. Это наш predict из середины урока, процитированный из первых рук. А тест с говорящим именем Test_App_Test_Goroutine_Leak_Compare открывает вторую страницу механики: горутина, потерянная по дедлайну. Когда FailOnTimeout true обрывает ожидание, коннект закрывается, но горутина хендлера ещё спит — она допишет ответ в закрытый буфер и завершится сама; тест специально сравнивает runtime.NumGoroutine() до и после и документирует, что при сработавшем дедлайне goroutine-утечка возможна и самоизлечима. Практический вывод: дедлайн теста — инструмент быстрого провала, а не способ «убить» хендлер; для медленных сценариев поднимайте Timeout или берите FailOnTimeout: false — тогда app.Test даст хендлеру дополнительную секунду дописать ответ и вернёт то, что успело уехать.

И последняя связка с прошлым уроком: env-конфигурация и graceful встречаются в одном тесте, когда вы проверяете, что Timeout из окружения действительно дошёл до конфига, — fiber.New(configFromEnv()), хендлер со Sleep, app.Test с ожиданием ответа в пределах дедлайна. Конфигурация без теста — надежда; тест без конфигурации — возможность; вместе — контракт.

Соберите файл урока целиком: buildApp, страж requireAPIKey из седьмого, jsonErrorHandler из четырнадцатого, configFromEnv из двадцатого — всё в одном пакете, тесты рядом в *_test.go. Команды прогона три. go test ./... — весь пакет со всеми тестами. go test -run TestListTasks -v — один тест по шаблону имени с подробным отчётом: t.Run-подтесты table-driven напечатаются отдельными строками со своими именами. go test -cover — покрытие, чтобы увидеть, какие ветки хендлеров прогон так и не потревожил. Приятная арифметика: весь урок исполняется за доли секунды, потому что ни один тест не открыл сокет.

Честное слово про инструментарий: песочница сайта Go-тесты не исполняет — runner-ов в уроках Fiber нет с первого урока, go test требует локального тулчейна, а интерактивы здесь quiz, predict, fill, order и флешкарты. Материал держится на исходниках ветки main ядра fiber v3.5.0: app.go — Test, TestConfig, ErrTestGotEmptyResponse; helpers.go — testConn над парой bytes.Buffer и errTestConnClosed; error.go — ErrHandlerExited; app_test.go — сто семьдесят вызовов, из которых мы процитировали Test_Test_Timeout, Test_App_Test_drop_empty_response и Test_App_Test_Goroutine_Leak_Compare. Граница темы: всё, что тестируется здесь, — транспортный контракт Fiber; бизнес-логика домена тестируется обычными тестами Go без fiber вообще, и чем меньше fiber в домене, тем быстрее тесты. Полный план курса — на странице курса Fiber.

Следующий, двадцать второй урок — структура большого проекта: слои, репозитории, DI-подход, вынос хендлеров из main. Тестовая база этого урока — его главный союзник, и вот почему. Сегодня buildApp вмещает один маршрут и одну фабрику; в двадцать втором маршрутов станет десятки, и фабрика разложится на конструкторы слоёв: buildApp станет собирать приложение из нужного среза — страж без логгера, роутер задач без статики, репозиторий над хранением в памяти вместо настоящей базы. Юнит-тесты этого урока при этом не изменятся ни строчкой: httptest.NewRequest, app.Test, io.ReadAll — тот же скелет работает поверх любой структуры проекта. Именно это и есть цель тестирования fiber: сделать рефакторинг скучным — а скучный рефакторинг это комплимент архитектуре.