在上一篇，介绍了表格驱动测试方法和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。
现在，我们使用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减肥瘦身。
