搞定Go單元測試（三）—— 斷言（testify）

時間 2019-11-06

標籤 git 程序員 github golang bash 框架單元測試測試 spa code 欄目 Git 简体版

原文原文鏈接

在上一篇，介紹了表格驅動測試方法和gomock測試框架，大大提高了測試效率與質量。本篇將介紹在測試中引入斷言（assertion），進一步提高測試效率與質量。git

爲何須要斷言庫

咱們先來看看Go標準包中爲何沒有斷言，官方在FAQ裏面回答了這個問題。程序員

golang.org/doc/faq#ass…github

整體歸納一下大意就是：「Go不提供斷言，咱們知道這會帶來必定的不便，其主要目的是爲了防止大家這些程序員在錯誤處理上偷懶。咱們知道這是一個爭論點，可是咱們以爲這樣很coooool~~。」因此，咱們引入斷言庫的緣由也很明顯了：偷懶，引入斷言能爲咱們提供便利——提升測試效率，加強代碼可讀性。golang

testify

在斷言庫的選擇上，咱們彷佛沒有過多的選擇，從start數和活躍度來看，基本上是testify一枝獨秀。bash

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。spa

總結一下

testify使用簡單，提高顯著，可謂是用一次就會愛上的懶人神器。在結合表格驅動測試，gomock和testify後，咱們已經能寫出一手優雅漂亮的單元測試代碼了。不過，光測試代碼優雅還不夠，咱們還須要幫main.go也打扮打扮。在下一篇，也是本系列最後一篇文章中，咱們將介紹wire依賴注入框架，幫main.go減肥瘦身。code