序言
对于领域对象的UT测试来说，基础设施层(infra)的操作函数都应该被打桩。对于Golang来说，大家通常会想到GoMock。GoMock是由Golang官方开发维护的针对Golang的Mock框架，代码在github.com上托管。GoMock目前已经实现了较为完整的基于interface的Mock功能，能够与Golang内建的testing包良好集成，使用GoMock编写的测试文件，能够直接使用go test命令进行测试，用户API简单友好。
尽管GoMock非常优秀，但是对于普通的函数打桩来说也有一些缺点：
- 必须引入额外的抽象(interface)
- 打桩过程比较重
- 既有代码必须适配新增的抽象
我们知道，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:
- 在函数前面新增“var ="
- 将函数名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
}
}
对上面的代码做些解释：
- 当tryTimes <= 0时，表示不重试，是普通的一次调用，该测试用例为错误测试；succOutputs是前面的len(succOutputs)次底层操作函数Exec正确调用的返回值切片
- 当tryTimes > 0时，表示重试，重试的失败次数为tryTimes - 1，最后一次重试成功，该测试为正确测试；succOutputs是前面的len(succOutputs) - 1次底层操作函数Exec正确调用的返回值与最后一次重试成功的返回值组成的切片
- 不管是否重试，错误时的返回值都是("", err)
测试funcA时，对函数Exec的打桩处理约定如下：
- 当前N(0 < N < M)次调用都返回正确但第N + 1次调用不管有无重试都返回错误时，使用ExecSeqInject打桩
- 当前N(0 < N < M)次调用都返回正确但第N + 1次调用有重试并且在最后一次重试时成功，使用ExecSeqInject打桩
- 其他情况属于简单场景，直接使用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，如有雷同，纯属巧合。
