Написание модульного теста для функции make-обработчика в Go-kit

Question

Моя проблема связана с Go-kit и с тем, как организовать код внутри.Я пытаюсь написать модульный тест для следующей функции:

func MakeHandler(svc Service, logger kitlog.Logger) http.Handler {
    orderHandler := kithttptransport.NewServer(
       makeOrderEndpoint(svc),
       decodeRequest,
       encodeResponse,
    )

    r := mux.NewRouter()
    r.Handle("/api/v1/order/", orderHandler).Methods("GET")

    return r

}

Каким будет правильный способ написания правильного модульного теста?Я видел примеры, такие как:

sMock := &ServiceMock{}
h := MakeHandler(sMock, log.NewNopLogger())

r := httptest.NewRecorder()
req := httptest.NewRequest("GET", "/api/v1/order/", bytes.NewBuffer([]byte("{}")))

h.ServeHTTP(r, req)

И затем тестирование тела и заголовков запроса.Но это не похоже на правильный модульный тест, так как вызывает другие части кода (orderHandler).Можно ли просто проверить, что возвращается из MakeHandler() вместо запроса?

Answer 1

TL; DR: Да, этот тест в правильном направлении.Вы не должны пытаться проверить внутреннюю часть возвращаемого обработчика, поскольку этот сторонний пакет может измениться так, как вы этого не ожидали в будущем.

Возможно ли просто проверить, что возвращено из MakeHandler() вместо во время запроса?

Не в хорошем смысле.MakeHandler() возвращает интерфейс, и в идеале вы должны использовать только методы интерфейса в своих тестах.

Вы можете просмотреть документы типа, возвращаемого mux.NewRouter(), чтобы увидеть, есть ли какие-либо поля или методы вконкретный тип, который может дать вам информацию, но это может оказаться проблемой - как для понимания тестов (еще один редко используемый тип для изучения), так и из-за того, как будущие модификации пакета mux могут повлиять на вашкод, не нарушая тесты.

Как правильно написать правильный модульный тест?

Ваш пример на самом деле в правильном направлении.При тестировании MakeHandler() вы проверяете, что возвращаемый им обработчик способен обрабатывать все пути и вызывает правильный обработчик для каждого пути.Поэтому вам нужно вызвать метод ServeHTTP(), дать ему сделать свое дело и затем проверить, чтобы он работал правильно.Только интроспекция обработчика не гарантирует корректность во время фактического использования.

Вам может потребоваться сделать действительно действительные запросы, хотя вы сможете понять, какой обработчик был вызван, основываясь на теле или заголовке ответа.Это должно привести тест к вполне разумному состоянию.(Я думаю, что у вас уже есть это)

Точно так же, я бы добавил базовый суб-тест для каждого маршрута, который будет добавлен в будущем.Подробные тесты обработчиков могут быть написаны в отдельных функциях.