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 R语言 拟时序分析降维图如何减少分支
  • ¥15 Fluent齿轮搅油
  • ¥15 八爪鱼爬数据为什么自己停了
  • ¥15 交替优化波束形成和ris反射角使保密速率最大化
  • ¥15 树莓派与pix飞控通信
  • ¥15 自动转发微信群信息到另外一个微信群
  • ¥15 outlook无法配置成功
  • ¥30 这是哪个作者做的宝宝起名网站
  • ¥60 版本过低apk如何修改可以兼容新的安卓系统
  • ¥25 由IPR导致的DRIVER_POWER_STATE_FAILURE蓝屏