阅读 556

搞定Go单元测试(三)—— 断言(testify)

在上一篇,介绍了表格驱动测试方法和gomock测试框架,大大提升了测试效率与质量。本篇将介绍在测试中引入断言(assertion),进一步提升测试效率与质量。

为什么需要断言库

我们先来看看Go标准包中为什么没有断言,官方在FAQ里面回答了这个问题。

golang.org/doc/faq#ass…

总体概括一下大意就是:“Go不提供断言,我们知道这会带来一定的不便,其主要目的是为了防止你们这些程序员在错误处理上偷懒。我们知道这是一个争论点,但是我们觉得这样很coooool~~。”所以,我们引入断言库的原因也很明显了:偷懒,引入断言能为我们提供便利——提高测试效率,增强代码可读性。

testify

在断言库的选择上,我们似乎没有过多的选择,从start数和活跃度来看,基本上是testify一枝独秀。

github.com/stretchr/te…

没有对比就没有伤害,先来看看使用testify之前的测试方法:

func TestSomeFun(t *testing.T){
...
    if v != want {
        t.Fatalf("v值错误,期望值:%s,实际值:%s", want, v)
    }
    if err != nil {
        t.Fatalf("非预期的错误:%s", err)
    }
    if objectA != objectB {
        if objectA.field1 !=  objectB.field1 {
            // t.Fatalf() field1值错误...bla bla bla
        }
         if objectA.field2 !=  objectB.field2 {
            // t.Fatalf() field2值错误...bla bla bla
        }
        // 遍历object所有值... bla bla bla
    }
...
}
复制代码

上述代码充斥着大量if...else..判断,大段错误信息拼装(真·体力活...),运气不好碰到结构体判断要得将其遍历一遍——不直观,低效,实在是不fashion。
现在,我们使用testify来改造一下上面的测试示例:

func TestSomeFun(t *testing.T){
    a := assert.New(t)
...
    a.Equal(v, want)
    a.Nil(err,"如果你还是想输出自己拼装的错误信息,可以传第三个参数")
    a.Equal(objectA, objectB)
...
}
复制代码

三行搞定,测试含义一目了然——直观,高效,简短,fashion。

总结一下

testify使用简单,提升显著,可谓是用一次就会爱上的懒人神器。在结合表格驱动测试,gomock和testify后,我们已经能写出一手优雅漂亮的单元测试代码了。不过,光测试代码优雅还不够,我们还需要帮main.go也打扮打扮。在下一篇,也是本系列最后一篇文章中,我们将介绍wire依赖注入框架,帮main.go减肥瘦身。

关注下面的标签,发现更多相似文章
评论