2 回答

TA貢獻1841條經驗 獲得超3個贊
根據您編寫測試的方式,您可能會依賴并忽略 linter 警告 ;
缺點是:您根據返回的錯誤的內部結構開始。reflect.DeepEqual()
在我閱讀的測試代碼和我們編寫的測試代碼中,我們使用以下模式之一:
大多數時候,我們只是將錯誤與
nil
;在某些情況下,我們的函數返回預定義的錯誤值,并測試這些特定值:
package pkg
var ErrUnboltedGizmo = errors.New("gizmo is unbolted")
// in test functions, depending on the case :
if err == pkg.ErrUnboltedGizmo { ...
// or :
if errors.Is(err, pkg.ErrUnboltedGizmo) { ...
當我們的生產代碼要求發現特定錯誤時(一個常見的用例是),我們編寫代碼來盡職盡責地包裝該已知錯誤,并且我們使用(在生產代碼和測試代碼中),io.EOFerrors.Is()
當需要僅在測試中松散地確認錯誤與某些內容匹配而不是其他內容(例如:而不是)時,我們只需在錯誤消息中搜索字符串:Parse errorFile not found
if err == nil || !strings.Contains(err.Error(), "database name is not exists") {
t.Errorf("unexpected error : %s", err)
}

TA貢獻1725條經驗 獲得超8個贊
我發現有用的是使用cmp。與 cmpopts 比較。IgnoreFields忽略導致問題的單獨錯誤字段,然后我只是用字符串對錯誤運行檢查。包含或我認為合適的任何東西。
所以它是這樣的:
if diff := cmp.Diff(expected, got, cmpopts.IgnoreFields(expected, "ErrorField")); diff != "" { // found diff not including the error }
現在只檢查自己的錯誤,僅此而已。
是的,我知道你已經標記了一個解決方案,但也許它會幫助某人:)
- 2 回答
- 0 關注
- 167 瀏覽
添加回答
舉報