前言
越来越觉得编写单元测试是程序员的基本素养
之前写单元测试都是基于go自己的test方式，基本就是在线下跑通流程，遇到下游的接口无法访问时，只会束手无策。后来了解到一些单测工具，仿佛打开了新世界的大门。市面上已有很多成熟的单测工具，本文不会比较各种工具的优劣，而是结合自身经验介绍笔者使用的几款工具。
我们在撰写单元测试的过程中其实关注的主要是两部分内容：断言和mock。
断言
断言(assertion)是一种在程序中的一阶逻辑(如：一个结果为真或假的逻辑判断式)，目的为了表示与验证软件开发者预期的结果——当程序执行到断言的位置时，对应的断言应该为真。 若断言不为真时，程序会中止执行，并给出错误信息。
说白了断言就是判断某个结果是否符合预期，这里比较推荐goconvey
比如针对以下方法，我们可以编写相关的单元测试用例如下
func Add(a, b int) int {
return a + b
}
import (
"testing"
. "github.com/smartystreets/goconvey/convey"
)
func TestAdd(t *testing.T) {
PatchConvey("test Add", t, func() {
PatchConvey("test 2+3=5", func() {
sum := Add(2, 3)
So(sum, ShouldEqual, 5)
})
PatchConvey("test 1+1 != 3", func() {
sum := Add(1, 1)
So(sum, ShouldNotEqual, 3)
})
})
}
从上述例子中我们可以看到，goconvey提供了Convey方法帮助我们进行测试用例的组织和编排，他能支持多级嵌套，方便我们进行case管理。
运行单元测试后，我们可以看到相关代码的覆盖率，这样可进一步帮助我们判断单测覆盖情况，查漏补缺。
mock
在单元测试中，模拟对象可以模拟复杂的、真实的（非模拟）对象的行为， 如果真实的对象无法放入单元测试中，使用模拟对象就很有帮助。
当我们的代码依赖较多，由于多种因素导致我们可能准确的控制这些依赖的返回值，比如你在线下环境测试，依赖的某些服务并没有部署线下环境，此时你的代码根本无法执行通过；如果直接在预览环境测试有可能导致线上风险，因此这时候我们就需要对这些下游服务的返回结果进行mock（关于mock工具比较推荐字节的mockey），使其按照我们预期的结果进行返回。
此处的下游不一定就是外部的服务，也可能是自身的方法或者函数。根据工作中实际场景，将mock分为如下几类：
mock对象方法
type Animal struct {}
func (t*Animal)Run() string {
return "animal run"
}
func AnimalRun() string {
animal := &Animal{}
return animal.Run()
}
func TestAnimalRun(t *testing.T) {
PatchConvey("test animal run", t, func() {
Mock((*Animal).Run).Return("animal jump").Build()
So(AnimalRun(), ShouldEqual, "animal jump")
})
}
我们通过Mock方法修改了Add函数的返回值恒定为10。注意：Return()方法中参数的数量要与被mock函数的返回值数量及其顺序保持一致。
mock函数
func Add(a, b int) int {
return a + b
}
func TwoSum(a, b int) int {
return Add(a, b)
}
import (
"testing"
. "github.com/bytedance/mockey"
. "github.com/smartystreets/goconvey/convey"
)
func TestTwoSum(t *testing.T) {
PatchConvey("test two sum", t, func() {
Mock(Add).Return(10).Build()
So(TwoSum(1, 2), ShouldEqual, 10)
})
}
序列化mock
在实际工作中会有这样一种场景，我们会会在一次请求处理中对某个方法调用多次，我们希望每次调用都可以返回不同的结果，这种该如何实现呢？别担心，mockey提供了序列化方式，可以统mock函数在多次执行中每次执行的结果，我们看下如何示例：
type Event struct {
Extra string `json:"extra"` // map
}
func parseEvent(value string) (map[string]interface{},error) {
event := &Event{}
if err := json.Unmarshal([]byte(value), &event); err != nil {
return nil, errors.New("unmarshal_event_failed")
}
ret := make(map[string]interface{})
if err := json.Unmarshal([]byte(event.Extra), &ret); err != nil {
return nil, errors.New("unmarshal_extra_failed")
}
return ret, nil
}
比如我们希望第一次unmarshal成功，第二次也成功，我们可以撰写如下单测
func TestParseEvent(t *testing.T) {
PatchConvey("test parse event", t, func() {
PatchConvey("test success", func() {
Mock(json.Unmarshal).Return(nil).Build() // 一次mock后续所有执行全部都是这个结果
ret, err := ParseEvent("")
So(ret, ShouldNotBeNil)
So(err, ShouldBeNil)
})
})
}
但是如果我希望第一次成功，第二次失败呢，使用上述方式就行不通了，我们可以这样写
func TestParseEvent(t *testing.T) {
PatchConvey("test parse event", t, func() {
PatchConvey("test unmarshal extra failed", func() {
Mock(json.Unmarshal).Return(Sequence(nil).Then(errors.New("unmarshal failed"))).Build()
ret, err := ParseEvent("")
So(ret, ShouldBeNil)
So(err.Error(), ShouldEqual, "unmarshal_extra_failed")
})
})
}
你可能会问，那我连续mock两次json.unmarshal是否可以的，答案当然是no，连续mock会导致异常，如：
func TestParseEvent(t *testing.T) {
PatchConvey("test parse event", t, func() {
PatchConvey("test unmarshal extra failed", func() {
// Mock(json.Unmarshal).Return(Sequence(nil).Then(errors.New("unmarshal failed"))).Build()
Mock(json.Unmarshal).Return(nil).Build()
Mock(json.Unmarshal).Return(errors.New("unmarshal failed")).Build()
ret, err := ParseEvent("")
So(ret, ShouldBeNil)
So(err.Error(), ShouldEqual, "unmarshal_extra_failed")
})
})
}
运行结果如下：会提示re-mock
Line 51: - re-mock <func([]uint8, interface {}) error Value>, previous mock at: /Users/bytedance/go/src/code.byted.org/namespace/test/unittest/exemple_test.go:50
goroutine 6 [running]:
FAQ
请移步参考官方文档
！！！这里建议执行单测是默认关闭内联优化，这样可以保证mock成功。
总结
保持写单测是一个很好的习惯，它可以辅助我们验证程序的逻辑正确性，同时让我们在重构一些代码时更加有信心控制风险（代码覆盖率足够高的前提下）同时也可以让我们放心的将一些代码交给新同学来开发。
虽然写单测会耗费一定的时间和精力，但总比线上出了问题擦屁股复盘强，不是吗？
目前笔者也还是小白阶段，会持续将实际工作中遇到的问题总结到本文，就算是当做学习笔记吧。
