go test 測試單個檔案和測試單個函式

測試單個檔案，一定要帶上被測試的原檔案

go test -v wechat_test.go wechat.go

測試單個方法

go test -v -test.run testrefreshaccesstoken

go 單元測試寫法

參考 testing

go語言package提供的自動化測試框架，

testing支援普通用例測試、壓力測試、並行測試，基本能滿足單測需求；

缺失：testing不支援mock資料，想要mock資料必須自己實現mock邏輯，這會增加許多不必要的工作量。

mock的重要性

理想情況下，乙個好的函式結構必須有入參、出參，完成的是一項單

一、獨立的工作，比如：

func add(a int, b int) int

這樣的函式寫單測很簡單，且輕易就能達到100%覆蓋率。

但實際工作中，這樣純粹的函式佔比可能不到10%，單個函式往往不是獨立的，它需要依賴於其他模組、三方庫、資料庫等等。

func uploadimage(content byte, uid string, fdfs *tsfdfs) error

database.createsample(…)

// 4. 繫結任務

binding := &database.examplennotationtask

database.createbinding(…)

return nil

}如果在單測中想要正常走完這個函式且不出錯，我們需要有乙個真實的fdfs環境可以上傳資料成功，乙個真實的資料庫，且根據業務邏輯，我們想要插入乙個sample前，必須有對應的enterprise、pipeline、annotation-task等等；

於是，在此前，專案中使用testing的單測實現思路是這樣的：

func testuploadimage(t *testing.t)

// 2. 連線真實的資料庫

db := database.newgormconn(…)

// 3. 插入一條enters資料

enters := &database.enterprisemodel

database.createenters(…)

// 4. 插入一條業務資料

…// 5. 插入另外一條業務資料

…// 6. 開始執行單測

uploadimage(…)…}

可以看到，單測之前進行了大量耗時的、冗餘的、無意義的工作

單測執行耗時長，正常一條單測時間一般在100ms內，在模擬了真實場景後，單測時間大幅增加，甚至專案中有部分單測超過1分鐘；

單測編碼效率低，需要了解了業務場景後，才能編寫完一條單測case；

過於依賴真實環境，穩定性差，維護成本高，對於一些無法模擬真實環境的流程，只能放棄覆蓋測試。

mock框架

gomonkey 單元測試

安裝

go get -u -v

github位址為：

參考部落格：

目前自己嘗試過mock方法把**使用的貼上供gopher參考下

這個地方是rpc呼叫其他服務,

測試中用打樁的方式，將這個

函式的結果先執行了，當執行

這個函式時，採用這個函式

打樁時mock的資料就可以了

對全域性變數、函式或過程打樁，對**中的外部依賴進行劫持並替換成mock的內容

為乙個全域性變數打樁

stubs := gostub.stub(&num, 10)

defer stubs.reset()

為乙個函式打樁

stubs := gostub.stubfunc(&func, func(args string) error )

defer stubs.reset()

為乙個過程打樁

stubs := gostub.stubfunc(&destroy)

defer stubs.reset()

場景組合

以上文測試上傳一張樣本為例

func testuploadimage(t *testing.t) )

defer stubs.reset()

// 2. stub 生成縮圖
stubs = gostub.stubfunc(&resize.resize, func() error )
// 3. stub sample create
stubs = gostub.stubfunc(&database.createsample, func() error )
...// 4. stub binding create
...// 5. 開始執行單測
uploadimage(...)
...

}

缺點對**有一定的侵入性 (需要將函式改為全域性變數語法形式、對三方庫需要做一層包裝)

無法對方法（成員函式）進行打樁

monkey

monkey是go的乙個猴子補丁（monkeypatching）框架，在執行時通過彙編語句重寫可執行檔案，將待打樁函式或方法的實現跳轉到樁實現，原理和熱補丁類似。

通過monkey可以解決stub無法為方法打樁的問題，但monkey不是執行緒安全的，不能用於併發測試。

為乙個函式打樁

guard := monkey.patch(func, func(args string) error )

defer guard.unpatch()

為乙個方法打樁

guard := monkey.patchinstancemethod(reflect.typeof(client), 「test」, func(args string) error )

defer guard.unpatch()

缺點執行緒不安全

在macos 10.15及以上版本無法執行，由於其原理是修改可執行檔案，從catalina版本起，系統對檔案讀寫許可權做了更嚴格的管理，monkey修改的檔案無寫許可權，執行panic，參考/issues/10

go test 測試單個檔案和測試單個函式

go test 測試單個檔案報錯問題

go test針對單個測試檔案構建失敗

go Test 單元測試測試框架

go test 測試單個檔案和測試單個函式

go test 測試單個檔案報錯問題

go test針對單個測試檔案構建失敗

go Test 單元測試 測試框架

相關推薦

go Test 單元測試測試框架