Golang

关注公众号 jb51net

关闭
首页 > 脚本专栏 > Golang > Golang单元测试

Golang实现单元测试中的接口层

作者：LinkinStar

接口层主要负责的就是请求的处理，最常见的就是 HTTP 请求的处理。这篇文章主要为大家介绍了Golang如何实现单元测试中的接口层，需要的可以参考一下

上次我们已经搞定了逻辑层的单元测试，这次我们来康康接口层的单元测试。接口层主要负责的就是请求的处理，最常见的就是 HTTP 请求的处理。

但针对 接口层 的单元测试其实是可以五花八门的。它并不像逻辑层和数据层一样的通用，对于它的测试往往有很多路可以走。

由于使用的 HTTP 框架不同，单元测试的实现方式则不同。 既可以通过程序来模拟 HTTP 请求，也可以通过真实的 HTTP 请求来测试，通过借助外部的一些测试工具来实现。

所以本文只能给出一种思路，具体的实现方式还是要根据实际的框架来实现。

环境

本文以常用的 gin 框架为例，使用一种个人比较喜欢也非常简单的方式来实现单元测试。特点主要有：

代码

由于之前已经贴过，所以 service 层的 代码这里就不赘述了

base case

package controller

import (
    "context"

    "github.com/gin-gonic/gin"
    "go-demo/m/unit-test/entity"
)

//go:generate mockgen -source=./user.go -destination=../mock/user_service_mock.go -package=mock
type UserService interface {
    AddUser(ctx context.Context, username string) (err error)
    GetUser(ctx context.Context, userID int) (user *entity.User, err error)
}

type AddUserRequest struct {
    Username string `json:"username" binding:"required"`
}

type GetUserRequest struct {
    UserID int `form:"user_id" binding:"required"`
}

type GetUserResponse struct {
    Username string `json:"username"`
}

type UserController struct {
    UserService UserService
}

func NewUserController(userService UserService) *UserController {
    return &UserController{UserService: userService}
}

func (uc *UserController) AddUser(ctx *gin.Context) {
    req := &AddUserRequest{}
    if err := ctx.BindJSON(req); err != nil {
        return
    }
    if err := uc.UserService.AddUser(ctx, req.Username); err != nil {
        ctx.JSON(400, gin.H{"error": err.Error()})
        return
    }
    ctx.JSON(200, gin.H{"message": "success"})
}

func (uc *UserController) GetUser(ctx *gin.Context) {
    req := &GetUserRequest{}
    if err := ctx.BindQuery(req); err != nil {
        return
    }
    user, err := uc.UserService.GetUser(ctx, req.UserID)
    if err != nil {
        ctx.JSON(400, gin.H{"error": err.Error()})
        return
    }
    ctx.JSON(200, &GetUserResponse{Username: user.Username})
}

单元测试

基础代码非常简单，就是我们常见的，最重要的让我们来看看单元测试应该怎么写

工具方法

在编写实际单元测试之前，我们需要一些工具方法来帮助我们构建一些请求。

func createGetReqCtx(req interface{}, handlerFunc gin.HandlerFunc) (isSuccess bool, resp string) {
    w := httptest.NewRecorder()
    c, _ := gin.CreateTestContext(w)
    encode := structToURLValues(req).Encode()
    c.Request, _ = http.NewRequest("GET", "/?"+encode, nil)
    handlerFunc(c)
    return w.Code == http.StatusOK, w.Body.String()
}

func createPostReqCtx(req interface{}, handlerFunc gin.HandlerFunc) (isSuccess bool, resp string) {
    responseRecorder := httptest.NewRecorder()
    ctx, _ := gin.CreateTestContext(responseRecorder)
    body, _ := json.Marshal(req)
    ctx.Request, _ = http.NewRequest("POST", "/", bytes.NewBuffer(body))
    ctx.Request.Header.Set("Content-Type", "application/json")

    handlerFunc(ctx)
    return responseRecorder.Code == http.StatusOK, responseRecorder.Body.String()
}

// 将结构体转换为 URL 参数
func structToURLValues(s interface{}) url.Values {
    v := reflect.ValueOf(s)
    if v.Kind() == reflect.Ptr {
        v = v.Elem()
    }
    t := v.Type()

    values := url.Values{}
    for i := 0; i < t.NumField(); i++ {
        field := t.Field(i)
        tag := field.Tag.Get("form")
        if tag == "" {
            continue
        }

        value := v.Field(i).Interface()
        values.Set(tag, valueToString(value))
    }

    return values
}

// 由于 get 请求常常参数并不会特别复杂，通常的几种类型就应该可以包括，有需要可以继续添加
func valueToString(v interface{}) string {
    switch v := v.(type) {
    case int:
        return strconv.Itoa(v)
    case string:
        return v
    default:
        return ""
    }
}

既然我们不想启动路由，其实最关键的问题就在如何构建一个 gin.Context 来模拟正常的请求。

单元测试

有了我们的工具方法，那么编写单元测试的时候就非常方便了，mock 方法和之前类似，剩下要调用对应的方法就可以了。并且这里可以复用我们已经在原有程序中使用的 请求结构 如 GetUserRequest 这样就可以不需要重新劳动了。

package controller

import (
    "fmt"
    "testing"

    "github.com/golang/mock/gomock"
    "github.com/stretchr/testify/assert"
    "go-demo/m/unit-test/entity"
    "go-demo/m/unit-test/mock"
)

func TestUserController_AddUser(t *testing.T) {
    ctl := gomock.NewController(t)
    defer ctl.Finish()

    req := &AddUserRequest{Username: "LinkinStar"}
    mockUserService := mock.NewMockUserService(ctl)
    mockUserService.EXPECT().AddUser(gomock.Any(), gomock.Any()).Return(nil)

    userController := NewUserController(mockUserService)

    success, resp := createPostReqCtx(req, userController.AddUser)
    assert.True(t, success)
    fmt.Println(resp)
}

func TestUserController_GetUser(t *testing.T) {
    ctl := gomock.NewController(t)
    defer ctl.Finish()

    req := &GetUserRequest{UserID: 1}
    user := &entity.User{Username: "LinkinStar"}
    mockUserService := mock.NewMockUserService(ctl)
    mockUserService.EXPECT().GetUser(gomock.Any(), gomock.Any()).Return(user, nil)

    userController := NewUserController(mockUserService)

    success, resp := createGetReqCtx(req, userController.GetUser)
    assert.True(t, success)
    fmt.Println(resp)
}

可以看到测试方法如出一辙，再详细的话只需要对请求的返回值做解析然后进行断言即可。

问题

当然以上述方式来实现单元测试的话，是会遗漏一些问题，毕竟偷懒是要有代价的。

针对这两个问题，我觉得可以由更加上层的测试来保证，由于这里仅仅是单元测试，我觉得这些代价还是可以接受的。并且，如果是使用 swagger 生成文档的情况下，也能保证文档和代码的统一性。但在此还是要出来提个醒，毕竟实际问题我还是遇到过的。

优化点

当然，这里的举例还是过于简单，实际中的请求往往会比较复杂。

总结

通常从现象来说，这一层的测试往往发现的问题比较少，是由于这一层的逻辑少，测试下来最常见的问题往往就是字段名称和限制条件不满足需求。所以其实从性价比的角度来说，单独对这层拿出来测试往往比较低，故实际中见到的比较少。

不过话又说回来了，本文的目的不仅仅是为了让你了解到可以这样写单元测试，其中使用的方法往往还能再某些时候让你复用 handler 的方法来保证系统的一致性。

到此这篇关于Golang实现单元测试中的接口层的文章就介绍到这了,更多相关Golang单元测试内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文