Golang Stub初体验

序言

对于领域对象的UT测试来说，基础设施层(infra)的操作函数都应该被打桩。对于Golang来说，大家通常会想到GoMock。GoMock是由Golang官方开发维护的针对Golang的Mock框架，代码在github.com上托管。GoMock目前已经实现了较为完整的基于interface的Mock功能，能够与Golang内建的testing包良好集成，使用GoMock编写的测试文件，能够直接使用go test命令进行测试，用户API简单友好。

尽管GoMock非常优秀，但是对于普通的函数打桩来说也有一些缺点：

1. 必须引入额外的抽象(interface)
2. 打桩过程比较重
3. 既有代码必须适配新增的抽象

我们知道，Golang支持闭包，这使得函数可以作为另一个函数的参数或返回值，而且可以赋值给一个变量。
闭包的特性使得笔者想到了Stub，于是开始了本文的体验。

Exec函数

Exec是infra层的一个操作函数，实现很简单，代码如下所示：

func Exec(cmd string, args ...string) (string, error) {
    cmdpath, err := exec.LookPath(cmd)
    if err != nil {
        log.Errorf("exec.LookPath err: %v, cmd: %s", err, cmd)
        return "", infra.ERR_EXEC_LOOKPATH_FAILED
    }

    var output []byte
    output, err = exec.Command(cmdpath, args...).CombinedOutput()
    if err != nil {
        log.Errorf("exec.Command.CombinedOutput err: %v, cmd: %s", err, cmd)
        return "", infra.ERR_EXEC_COMBINED_OUTPUT_FAILED
    }
    log.Info("CMD[", cmdpath, "]ARGS[", args, "]OUT[", string(output), "]")
    return string(output), nil
}

Stub设计

物理设计

stub位于test目录下，和*test目录或文件并行为*stub，比如
test/infra-test/os-encap-test/exec_test.go ==>
test/infra-stub/os-encap-stub/exec_stub.go

既有函数重构

Exec函数的重构非常简单，only and only:

1. 在函数前面新增“var ="
2. 将函数名Exec移动到”=“前面

// infra/os-encap/exec.go
var Exec = func(cmd string, args ...string) (string, error) {
    cmdpath, err := exec.LookPath(cmd)
    if err != nil {
        log.Errorf("exec.LookPath err: %v, cmd: %s", err, cmd)
        return "", infra.ERR_EXEC_LOOKPATH_FAILED
    }

    var output []byte
    output, err = exec.Command(cmdpath, args...).CombinedOutput()
    if err != nil {
        log.Errorf("exec.Command.CombinedOutput err: %v, cmd: %s", err, cmd)
        return "", infra.ERR_EXEC_COMBINED_OUTPUT_FAILED
    }
    log.Info("CMD[", cmdpath, "]ARGS[", args, "]OUT[", string(output), "]")
    return string(output), nil
}

这样简单的重构后，还有一个大的优势是Exec函数的调用将保持不变。

Stub函数

Exec的Stub函数我们命名为ExecInject，它的设计和实现非常简单，即ExecInject函数有多个入参，没有返回值，而且入参列表和Exec函数的返回值列表一一对应，代码如下所示：

// test/infra-stub/oscap-stub/exec_stub.go
func ExecInject(output string, err error) {
    osencap.Exec = func(cmd string, args ...string) (string, error) {
        return output, err
    }
}

Stub序列函数

当在同一个函数funcA中存在M次调用底层操作函数Exec，并且任意一次Exec调用可以重试R次时，这时打桩就需要用到Stub序列函数ExecSeqInject，代码如下所示：

// test/infra-stub/oscap-stub/exec_stub.go
func ExecSeqInject(succOutputs []string, tryTimes int, err error) {
    i := 0
    length := 0
    tryFailTimes := 0
    needTry := false
    if tryTimes == 0 {
        length = len(succOutputs)
    } else {
        length = len(succOutputs) - 1
        needTry = true
        tryFailTimes = tryTimes - 1
    }

    osencap.Exec = func(cmd string, args ...string) (string, error) {
        if i < length {
            i++
            return succOutputs[i - 1], nil
        }
        if needTry {
            if tryFailTimes > 0 {
                tryFailTimes--
                return "", err
            }
        } else {
            return "", err
        }


        return succOutputs[i], nil
    }
}

对上面的代码做些解释：

1. 当tryTimes <= 0时，表示不重试，是普通的一次调用，该测试用例为错误测试；succOutputs是前面的len(succOutputs)次底层操作函数Exec正确调用的返回值切片
2. 当tryTimes > 0时，表示重试，重试的失败次数为tryTimes - 1，最后一次重试成功，该测试为正确测试；succOutputs是前面的len(succOutputs) - 1次底层操作函数Exec正确调用的返回值与最后一次重试成功的返回值组成的切片
3. 不管是否重试，错误时的返回值都是("", err)

测试funcA时，对函数Exec的打桩处理约定如下：

1. 当前N(0 < N < M)次调用都返回正确但第N + 1次调用不管有无重试都返回错误时，使用ExecSeqInject打桩
2. 当前N(0 < N < M)次调用都返回正确但第N + 1次调用有重试并且在最后一次重试时成功，使用ExecSeqInject打桩
3. 其他情况属于简单场景，直接使用ExecInject打桩

Stub验证

我们共写四个UT用例来验证Stub是否生效，前两个用例针对Stub函数，后两个用例针对Stub序列函数，需要考虑原函数的备份和恢复，即在stub前备份，在测试完成后恢复。

第一个UT用例，测试正确情况下Stub函数是否成功注入，代码如下所示：

func TestStubDemoForSucc(t *testing.T) {
    backup := osencap.Exec
    defer func() {
        osencap.Exec = backup
    }()

    convey.Convey("stub demo for succ\n", t, func() {
        outputExpect := "xxx-vethName100-yyy"
        osencapstub.ExecInject(outputExpect, nil)
        output, err := osencap.Exec(any, any)
        convey.So(err, convey.ShouldEqual, nil)
        convey.So(output, convey.ShouldEqual, outputExpect)
    })
}

第二个UT用例，测试错误情况下Stub函数是否成功注入，错误对象的个数决定了Stub注入的次数，代码如下所示：

const any = "any"

func TestStubDemoForFail(t *testing.T) {
    backup := osencap.Exec
    defer func() {
        osencap.Exec = backup
    }()

    convey.Convey("stub demo for fail\n", t, func() {
        osencapstub.ExecInject("", infra.ERR_EXEC_LOOKPATH_FAILED)
        _, err := osencap.Exec(any, any)
        convey.So(err, convey.ShouldEqual, infra.ERR_EXEC_LOOKPATH_FAILED)

        osencapstub.ExecInject("", infra.ERR_EXEC_COMBINED_OUTPUT_FAILED)
        _, err = osencap.Exec(any, any)
        convey.So(err, convey.ShouldEqual, infra.ERR_EXEC_COMBINED_OUTPUT_FAILED)
    })
}

第三个UT用例，测试Stub序列函数在错误的场景是否成功注入，代码如下所示：

func TestStubSeqDemoForFailAfter2Succ(t *testing.T) {
    backup := osencap.Exec
    defer func() {
        osencap.Exec = backup
    }()

    convey.Convey("stub seq demo for fail after two times succ\n", t, func() {
        outputsExpect := []string{"ok", "xxx-vethName100-yyy"}
        osencapstub.ExecSeqInject(outputsExpect, 0, infra.ERR_EXEC_LOOKPATH_FAILED, )
        output, err := osencap.Exec(any, any)
        convey.So(err, convey.ShouldEqual, nil)
        convey.So(output, convey.ShouldEqual, outputsExpect[0])

        output, err = osencap.Exec(any, any)
        convey.So(err, convey.ShouldEqual, nil)
        convey.So(output, convey.ShouldEqual, outputsExpect[1])

        _, err = osencap.Exec(any, any)
        convey.So(err, convey.ShouldEqual, infra.ERR_EXEC_LOOKPATH_FAILED)
    })
}

第四个UT用例，测试Stub序列函数在正确的场景是否成功注入，代码如下所示：

func TestStubSeqDemoForSuccWithTryAfter2Succ(t *testing.T) {
    backup := osencap.Exec
    defer func() {
        osencap.Exec = backup
    }()

    convey.Convey("stub seq demo for succ with try after two times succ\n", t, func() {
        outputsExpect := []string{"ok", "xxx-vethName100-yyy", "success"}
        maxTryTimes := 10
        osencapstub.ExecSeqInject(outputsExpect, maxTryTimes, infra.ERR_EXEC_LOOKPATH_FAILED, )
        output, err := osencap.Exec(any, any)
        convey.So(err, convey.ShouldEqual, nil)
        convey.So(output, convey.ShouldEqual, outputsExpect[0])

        output, err = osencap.Exec(any, any)
        convey.So(err, convey.ShouldEqual, nil)
        convey.So(output, convey.ShouldEqual, outputsExpect[1])

        for i := 0; i < maxTryTimes - 1; i++ {
            _, err = osencap.Exec(any, any)
            convey.So(err, convey.ShouldEqual, infra.ERR_EXEC_LOOKPATH_FAILED)
        }
        output, err = osencap.Exec(any, any)
        convey.So(err, convey.ShouldEqual, nil)
        convey.So(output, convey.ShouldEqual, outputsExpect[2])
    })
}

小结

对于Golang来说，很多同学喜欢用GoMock打桩。不可否认，GoMock非常优秀，但对于底层的操作函数使用GoMock打桩会引入额外的复杂度，因此笔者想尝试其他方式。本文借助闭包的特性对底层的操作函数进行打桩，根据场景的不同将打桩函数分为Stub函数和Stub序列函数，简单实用，希望对读者有一定的启发。为了便于记忆和交流，笔者将这种方法命名为Golang Stub，如有雷同，纯属巧合。