dounei5721 2018-09-11 17:32
浏览 67
已采纳

为Go-kit中的make handler功能编写单元测试

My problem is specific to Go-kit and how to organize code within. I'm trying to write a unit test for the following function:

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

}

What would be the correct way of writing a proper unit test? I have seen examples such as the following:

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

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

h.ServeHTTP(r, req)

And then testing the body and headers of the request. But this doesn't seem like a proper unit test, as calls other parts of the code (orderHandler). Is it possible to just validate what's returned from MakeHandler() instead of during a request?

  • 写回答

1条回答 默认 最新

  • dreljie602951 2018-09-12 00:43
    关注

    TL;DR: Yes, that test is in the right direction. You shouldn't try to test the internals of the returned handler since that third party package may change in ways you didn't expect in the future.

    Is it possible to just validate what's returned from MakeHandler() instead of during a request?

    Not in a good way. MakeHandler() returns an interface and ideally you'd use just the interface methods in your tests.

    You could look at the docs of the type returned by mux.NewRouter() to see if there are any fields or methods in the concrete type that can give you the information, but that can turn out to be a pain - both for understanding the tests (one more rarely used type to learn about) and due to how future modifications to the mux package may affect your code without breaking the tests.

    What would be the correct way of writing a proper unit test?

    Your example is actually in the right direction. When testing MakeHandler(), you're testing that the handler returned by it is able to handle all the paths and calls the correct handler for each path. So you need to call the ServeHTTP() method, let it do its thing and then test to see it worked correctly. Only introspecting the handler does not guarantee correctness during actual usage.

    You may need to make actually valid requests though so you're able to understand which handler was called based on the response body or header. That should bring the test to a quite reasonable state. (I think you already have that)

    Similarly, I'd add a basic sub test for each route that's added in the future. Detailed handler tests can be written in separate funcs.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥15 2020长安杯与连接网探
  • ¥15 关于#matlab#的问题:在模糊控制器中选出线路信息,在simulink中根据线路信息生成速度时间目标曲线(初速度为20m/s,15秒后减为0的速度时间图像)我想问线路信息是什么
  • ¥15 banner广告展示设置多少时间不怎么会消耗用户价值
  • ¥16 mybatis的代理对象无法通过@Autowired装填
  • ¥15 可见光定位matlab仿真
  • ¥15 arduino 四自由度机械臂
  • ¥15 wordpress 产品图片 GIF 没法显示
  • ¥15 求三国群英传pl国战时间的修改方法
  • ¥15 matlab代码代写,需写出详细代码,代价私
  • ¥15 ROS系统搭建请教(跨境电商用途)