從頭到腳說單測——談有效的單元測驗（上篇）

一. 為單元測驗“正名”

我曾經認為，單元測驗面向的是一個函式，任何走出一個函式的測驗，都不是單元測驗，

其實，對“單元”的定義取決于自己，如果你正在使用函式式編程，一個單元最有可能指的是一個函式，你的單元測驗將使用不同的引數呼叫這個函式，并斷言它回傳了期待的結果；在面向物件語言里，下至一個方法，上至一個類都可以是一個單元（從一個單一的方法到一整個的類都可以是一個單元），意圖很重要（“意圖”二字是本文中第一次提到，它很重要）

我們有單元測驗、增量測驗、集成測驗、回歸測驗、冒煙測驗等等，名字非常多，谷歌看到這種“百家爭鳴”的現象，創立了自己的命名方式，只分為小型測驗、中型測驗和大型測驗，

·小型測驗，針對單個函式的測驗，關注其內部邏輯，mock所有需要的服務，

小型測驗帶來優秀的代碼質量、良好的例外處理、優雅的錯誤報告

·中型測驗，驗證兩個或多個制定的模塊應用之間的互動

·大型測驗，也被稱為“系統測驗”或“端到端測驗”，大型測驗在一個較高層次上運行，驗證系統作為一個整體是如何作業的，

結論：我們的單元測驗，既可以針對一個函式寫case，也可以按照函式的呼叫關系串起來寫case，

二. 金字塔模型

在金字塔模型之前，流行的是冰淇淋模型，包含了大量的手工測驗、端到端的自動化測驗及少量的單元測驗，造成的后果是，隨著產品壯大，手工回歸測驗時間越來越長，質量很難把控；自動化case頻頻失敗，每一個失敗對應著一個長長的函式呼叫，到底哪里出了問題？單元測驗少的可憐，基本沒作用，

Mike Cohn 在他的著作《Succeeding with Agile》一書中提出了“測驗金字塔”這個概念，這個比喻非常形象，它讓你一眼就知道測驗是需要分層的，它還告訴你每一層需要寫多少測驗，

測驗金字塔本身是一條很好的經驗法則，我們最好記住Cohn在金字塔模型中提到的兩件事：

·撰寫不同粒度的測驗

·層次越高，你寫的測驗應該越少

同時，我們對金字塔的理解絕不能止步于此，要進一步理解：

我把金字塔模型理解為——冰激凌融化了，就是指，最頂部的“手工測驗”理論上全部要自動化，向下融化，優先全部考慮融化成單元測驗，單元測驗覆寫不了的 放在中間層（分層測驗），再覆寫不了的才會放到UI層，因此，UI層的case，能沒有就不要有，跑的慢還不穩定，按照喬幫主的說法，我不分單元測驗還是分層測驗，統一都叫自動化測驗，那就應該把所有的自動化case看做一個整體，case不要冗余，單元測驗能覆寫，就要把這個case從分層或ui中去掉，

越是底層的測驗，牽扯到相關內容越少，而高層測驗則涉及面更廣，比如單元測驗，它的關注點只有一個單元，而沒有其它任何東西，所以，只要一個單元寫好了，測驗就是可以通過的；而集成測驗則要把好幾個單元組裝到一起才能測驗，測驗通過的前提條件是，所有這些單元都寫好了，這個周期就明顯比單元測驗要長；系統測驗則要把整個系統的各個模塊都連在一起，各種資料都準備好，才可能通過，

另外，因為涉及到的模塊過多，任何一個模塊做了調整，都有可能破壞高層測驗，所以，高層測驗通常是相對比較脆弱的，在實際的作業中，有些高層測驗會牽扯到外部系統，這樣一來，復雜度又在不斷地提升，

三. 為什么做單測

這個問題我們規避不掉，新聞是這次研發模式改革的主力軍之一，所以自上而下的推動讓這個問題不那么棘手：做了就是做了，不做，卻又有那么多的理由：

（搜集到的吐槽真實聲音）

· 單元測驗浪費了太多的時間

· 單元測驗僅僅是證明這些代碼做了什么

· 我是很棒的程式員，我是不是可以不進行單元測驗？

· 后面的集成測驗將會抓住所有的bug

· 單元測驗的成本效率不高我把測驗都寫了，那么測驗人員做什么呢？

· 公司請我來是寫代碼，而不是寫測驗

· 測驗代碼的正確性，并不是我的作業

單元測驗的意義

·單元測驗對我們的產品質量是非常重要的，

·單元測驗是所有測驗中最底層的一類測驗，是第一個環節，也是最重要的一個環節，是唯一一次有保證能夠代碼覆寫率達到100%的測驗，是整個軟體測驗程序的基礎和前提，單元測驗防止了開發的后期因bug過多而失控，單元測驗的性價比是最好的，

·據統計，大約有80%的錯誤是在軟體設計階段引入的，并且修正一個軟體錯誤所需的費用將隨著軟體生命期的進展而上升，錯誤發現的越晚，修復它的費用就越高，而且呈指數增長的趨勢，作為編碼人員，也是單元測驗的主要執行者，是唯一能夠做到生產出無缺陷程式這一點的人，其他任何人都無法做到這一點

·代碼規范、優化，可測驗性的代碼

·放心重構

·自動化執行three-thousand times

下面這張圖，來自微軟的統計資料：bug在單元測驗階段被發現，平均耗時3.25小時，如果漏到系統測驗階段，要花費11.5小時，

下面這張圖，旨在說明兩個問題：85%的缺陷都在代碼設計階段產生，而發現bug的階段越靠后，耗費成本就越高，指數級別的增高，所以，在早期的單元測驗就能發現bug，省時省力，一勞永逸，何樂而不為呢，

單元測驗特別耗時？

不能一刀切，不能只盯著單測階段的耗時，

我采訪了新聞客戶端、后臺的開發，首先肯定的是，單測會增加開發量、增加開發時長；

在《單元測驗的藝術》這本書提到一個案例：找了開發能力相近的兩個團隊，同時開發相近的需求，進行單測的團隊在編碼階段時長增長了一倍，從7天到14天，但是，這個團隊在集成測驗階段的表現非常順暢，bug量小，定位bug迅速等，最終的效果，整體交付時間和缺陷數，均是單測團隊最少，

單測，存在即合理，一方面，需要把單測放在整個迭代周期來觀測其效果；一方面，寫單測也是技識訓，寫得好的同學，時間少代碼質量高（也即，不是說寫了單測，就能寫好單測）

誰來寫單測呢？

·開發同學寫單測

·測驗同學具有寫單測的能力，重點在于開發腳手架、分層測驗/端到端測驗

增量還是存量

·單測case針對增量代碼

·當存量代碼出現大規模重構，后者質量暴露出極大風險時，都是推動補全單測的好時機

四. 單元測驗的階段

一. 廣義的單元測驗，我們指這三部分的有機組合：

·code review

·靜態代碼掃描

·單元測驗用例撰寫

二. 結合新聞的實踐，我把單測成長的程序分為4個目標，分別為：

·會寫，全員可寫

·寫的好，同時關注可測性問題，試點解決

·識別可測性問題，熟練使用重構方法進行重構；識別代碼架構設計問題；case與業務代碼同步撰寫

·TDD，但這個目標是期望，不能作為必須實作的目標，

截至發稿當天，新聞處于第三階段，即，每個迭代均能產出高質量的case，人數覆寫和需求覆寫均較高；關注重點在于可測性，時刻注重重構，

五. 單元測驗的指標

還挺尷尬的，不太有直接的指標去衡量單測的效果，我們也經常被問到，“怎么證明你們新聞單測的作用呀？”

·bug類指標（間接指標）：連續迭代的bug總數趨勢、迭代內新建bug的趨勢、千行bug率

·單測的需求覆寫度（50%以上），參與人員覆寫度（80%以上）

·單測case總數趨勢，代碼行增量趨勢

·增量代碼的行覆寫率（接入層80%，客戶端30%）

·單函式圈復雜度（低于40），單函式代碼行數（低于80），掃描告警數

在迭代需求持續高吞吐量的前提下，以新聞iOS的資料為例：

六. go單元測驗框架選型

基本選型：testify + gomonkey

附加：httptest + sqlmock

前提

·測驗檔案，以_test.go結尾，與被測檔案放于相同目錄

·測驗函式，函式名以Test開頭，并且隨后的第一個字符必須為大寫字母或下劃線，如：TestParseReq_CorrectNum_TableDriven

·測驗函式，引數為t *testing.T；對于bench測驗，引數為b *testing.B

·運行命令列，我的文章有深入講解：go test命令列

testify常規用法

https://github.com/stretchr/testify

testify基于gotesting撰寫，所以語法上、執行命令列與go test完全兼容

支持大量高效的api，比如：

assert.Equal：常規對比，是把兩者分別換成[]byte去嚴格比對

assert.Nil：判斷物件為nil時，有時對err判空時也用

assert.Error：判斷err的具體型別和內容

assert.JSONEq：這個比較有用，對比map時；或者對比struct的時候，也會先轉為map，在用這個api去做對比，如下面這個例子，我封裝了建議的方法去將struct轉換為string(json)：

·支持suite，用例集管理

·運行時，可以指定用例集執行

·自帶mock工具，但只支持介面方法的mock，而且用法相對復雜

·table-driven

gomonkey用法（藍色字體表示常用）

https://github.com/agiledragon/gomonkey

https://studygolang.com/articles/15034

·支持為一個函式打一個樁

·支持為一個成員方法打一個樁

·支持為一個全域變數打一個樁

·支持為一個函式變數打一個樁

·支持為一個函式打一個特定的樁序列

·支持為一個成員方法打一個特定的樁序列

·支持為一個函式變數打一個特定的樁序列

·table-driven的方式定義一系列stub

注意，對行內函式的Stub，go test命令列一定要加上引數才可生效，見官方檔案，所以，我的命令列默認加上-gcflags=all=-l就行了，

我設定了一些goland的代碼模板，放在附件中，

ApplyFunc是對外部函式Stub（非類方法）

/* 用法：gomonkey.ApplyFunc(被stub函式名, 被stub函式簽名) 函式回傳值

*例子：

patches := gomonkey.ApplyFunc(fake.Exec, func(_ string, _ ...string) (string, error) {

return outputExpect, nil

})

*/

patches := gomonkey.ApplyFunc(lcache.GetCache, func(_ string) (interface{}, bool) {

return getCommentsResp()

})

defer patches.Reset()

ApplyMethod是對類函式Stub，但這里注意，要被stub的方式是私有方法，gomonkey通過反射是找不到的，有兩種解決方法：1）使用增強版的gomonkey；2）不Stub它，而是選擇走進這個函式，這個話題在后面專題談mock的時候說，

/* 用法：gomonkey.ApplyMethod(反射類名, 被stub函式簽名) 函式回傳值

*例子：

var s *fake.Slice

patches := ApplyMethod(reflect.TypeOf(s), "Add", func(_ *fake.Slice, _ int) error {

return nil

})

*/

var ac *auth.AuthCheck

patches := gomonkey.ApplyMethod(reflect.TypeOf(ac), "PrepareWithHttp", func(_ *auth.AuthCheck, _ *http.Request, _ ...auth.AuthOption) error {

return fmt.Errorf("prepare with nil object")

})

defer patches.Reset()

ApplyMethodSeq是對同一個Stub的函式回傳不同的結果

/* 用法：gomonkey.ApplyMethodSeq(類的反射，"被stub函式名", 回傳結構體)；

Params{info1},中括號內為被stub函式的回傳值串列；

Times為生效次數

*例子：

e := &fake.Etcd{}

info1 := "hello cpp"

info2 := "hello golang"

info3 := "hello gomonkey"

outputs := []OutputCell{

{Values: Params{info1, nil}},

{Values: Params{info2, nil}},

{Values: Params{info3, nil}},

}

patches := ApplyMethodSeq(reflect.TypeOf(e), "Retrieve", outputs)

defer patches.Reset()

*/

conn := &redis.RedisConn{}

patch1 := gomonkey.ApplyFunc(redis.NewRedisHTTP, func(serviceName string, _ string) *redis.RedisConn {

conn := &redis.RedisConn{

redis.RedisConfig{},

&redis.RedisHelper{},

}

return conn

})

defer patch1.Reset()

// mock redis data. 回傳空和不為空的情況

outputCell := []gomonkey.OutputCell{

{Values: gomonkey.Params{"12", nil}, Times: 1},

{Values: gomonkey.Params{"", nil}, Times: 1},

}

patchs := gomonkey.ApplyMethodSeq(reflect.TypeOf(conn.RedisHelper), "Get", outputCell)

defer patchs.Reset()

先舉這幾個例子，詳細的可以在上面的鏈接文章中全面得到，

這里補充一點，對類方法進行stub，必須要找到該方法對應的真實的類（結構體），舉個例子：

//被測函式中有如下一段，其中的Get方法我們想stub掉，只要找到Get方法對應的類就好了

readCountStr, _ := conn.Get(redisKey)

if len(readCountStr) == 0 {

return 0, nil

}

定位conn，是RedisConn型別的struct

type RedisConn struct {

RedisConfig

*RedisHelper

}

所以第一次，我用gomonkey.AppleyMethod時這么寫：

patches := gomonkey.ApplyMethod(reflect.TypeOf(*RedisConn),"Get", func(_ *redis.RedisHelper,_ string, _ []string) ([]string, error){

return info,err_notNil

})

defer patches.Reset()

WeTest小編提醒：上篇的內容就到這里，相信大家肯定還沒看夠吧~在下篇會說到關于mock、和如何不要濫用mock等等更多精彩的內容，讓我們趕緊一起來看下吧~《從頭到腳說單測——談有效的單元測驗（下篇）》

關注騰訊WeTest，了解更多熱門測驗產品：WeTest騰訊質量開放平臺 - 專注游戲，提升品質