在上一篇，介紹了表格驅動測試方法和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減肥瘦身。

轉載于:https://juejin.im/post/5ce935a1e51d4510aa01147b

總結

以上是生活随笔為你收集整理的搞定Go单元测试（三）—— 断言（testify）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。