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

为什么需要断言库

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

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

testify

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

没有对比就没有伤害，先来看看使用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。

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减肥瘦身。