1、如何編寫單元測試

在任何生產級別的項目開發中，單元測試都扮演著至關重要的角色。盡管許多初創項目在早期可能忽略了它，但隨著項目逐漸成熟并成為核心業務，為其編寫健壯的單元測試是保障代碼質量和項目穩定性的必然選擇。本文將帶您快速掌握 Go 語言中單元測試的基本方法和核心概念。

1、核心命令：go test

Go 語言的測試工具鏈非常簡潔，其核心是 go test 命令。這是一個依據特定約定來組織和驅動測試代碼的程序。當你在一個包目錄中執行 go test 時，它會自動尋找并執行所有符合測試規范的用例。

2、測試文件的約定

go test 命令的運行依賴于一套簡單的文件和函數命名約定：

1. 文件名約定：在包目錄中，所有以 _test.go 為后綴的源文件都會被 go test 命令識別為測試文件并執行。
2. 構建時排除：您無需擔心測試文件會增加最終可執行文件的大小。go build 命令在編譯和打包時會自動忽略這些 _test.go 文件，確保它們只存在于測試環境中。

3、測試函數的類型

在 _test.go 文件中，我們主要會編寫以下幾種類型的測試函數，目前我們主要關注前兩種：

• 功能測試 (Functional Tests)：函數名以 Test 開頭，例如 TestMyFunction。這是最常見的測試類型，用于驗證代碼功能的正確性。
• 性能測試 (Benchmark Tests)：函數名以 Benchmark 開頭，例如 BenchmarkMyFunction。用于衡量代碼的性能和效率。
• 示例測試 (Example Tests)：函數名以 Example 開頭，用于提供可執行的示例代碼，常用于文檔生成。
• 模糊測試 (Fuzzing Tests)：以 Fuzz 開頭，是一種自動化的測試技術，用于發現邊界條件下的潛在錯誤。

4、編寫第一個單元測試

讓我們通過一個具體的例子來演示如何編寫和運行一個單元測試。

1. 準備被測試的代碼

首先，我們創建一個 add.go 文件，并在其中定義一個簡單的加法函數。

2. 創建測試文件

接下來，在與 add.go 相同的包（目錄）下，我們創建測試文件 add_test.go。將測試文件和源文件放在同一包內，可以方便地測試包內未導出的（小寫字母開頭的）函數和方法。

3. 編寫測試函數

在 add_test.go 文件中，我們編寫一個功能測試函數來驗證 Add 函數的正確性。

測試函數的規范：

• 函數名必須以 Test 開頭，后面通常跟上被測試的函數名，如 TestAdd。
• 參數必須是 t *testing.T。*testing.T 類型提供了報告測試失敗和記錄日志等核心功能。

編寫完成后，許多 IDE（如 GoLand）會自動在函數旁顯示一個可運行的標記，這表明 IDE 已經識別出這是一個有效的測試用例。

2、管理和跳過耗時測試

當測試用例數量增多時，某些測試（如涉及網絡請求或大量計算的測試）可能會運行得非常緩慢。為了在開發過程中獲得快速反饋，我們常常希望可以跳過這些耗時的測試。

Go 語言為此提供了 -short 模式。

工作原理

1. 在運行測試時，可以附加 -short 標志：go test -v -short。
2. 在測試函數內部，可以通過 testing.Short() 函數進行判斷。如果 -short 標志被設置，該函數返回 true。
3. 使用 t.Skip() 方法來跳過當前測試。當 t.Skip() 被調用時，該測試函數會立即終止，并被標記為“已跳過”（SKIPPED），而不會被標記為“失敗”（FAILED）。

讓我們添加一個模擬的耗時測試 TestLongRunningTask。

.正常模式

執行 go test -v，所有測試都會運行，包括耗時的測試。

可以看到，總耗時超過了2秒。

b. Short 模式

執行 go test -v -short，耗時的測試將被跳過。

可以看到，TestLongRunningTask 被標記為 SKIP，并且總耗時非常短。通過這種方式，我們可以靈活地控制運行哪些測試用例，從而提升開發效率。

3、表格驅動測試 (Table-Driven Tests)

當我們需要用多組不同的輸入和期望輸出來測試同一個函數時（例如，測試正常情況、邊界情況、異常情況），為每一組數據編寫一個獨立的 Test 函數會非常繁瑣且難以維護。

表格驅動測試模式優雅地解決了這個問題。其核心思想是將所有測試用例定義在一個“表格”（通常是一個結構體切片）中，然后在一個測試函數內遍歷這個表格，執行每一個測試用例。

實現步驟

1. 定義測試用例結構體：創建一個結構體，用于描述一個完整的測試用例，包含輸入參數和期望的輸出結果。
2. 創建測試用例表格：聲明一個該結構體的切片，并填充所有需要測試的數據。
3. 遍歷表格執行測試：在測試函數中，使用 for 循環遍歷切片。對于每個測試用例，執行被測函數并斷言結果。
4. (推薦) 使用 t.Run 創建子測試：在循環中為每個測試用例創建一個子測試。這樣做的好處是，所有測試用例都會被執行（即使中途有失敗），并且測試結果會清晰地分組展示，便于定位問題。

代碼示例

讓我們用表格驅動模式來重構 TestAdd。

當我們運行這個測試時，如果出現錯誤（例如，我們將第三個用例的期望值 expected 錯寫成 0），會得到非常清晰的報告。

這個輸出明確地告訴我們，只有名為 input:_-9,_8 的子測試失敗了，極大地提高了調試效率。

4、性能測試 (Benchmark Tests)

除了功能正確性，代碼的性能也是衡量質量的重要維度。對于一些位于核心路徑、對性能有高要求的函數，我們需要進行性能測試。Go 語言內置了強大的性能測試框架。

性能測試的規范

• 函數命名：性能測試函數必須以 Benchmark 開頭，例如 BenchmarkAdd。
• 函數簽名：參數必須是 b *testing.B。*testing.B 類型提供了控制計時器、設置迭代次數等能力。
• 核心循環：測試的主體邏輯必須放在一個 for 循環內，循環次數由 b.N 決定：for i := 0; i < b.N; i++。go test 命令會自動調整 b.N 的值，反復運行代碼直到獲得穩定可靠的測量結果。

簡單示例

實踐：比較字符串拼接性能

字符串拼接是一個非常常見的操作，不同的實現方式性能差異巨大。下面我們通過性能測試來實際比較三種方法的優劣：fmt.Sprintf、+ 操作符和 strings.Builder。

通過命令行運行測試 使用 go test 命令并附加 -bench 標志。. 作為參數表示運行當前包下所有的性能測試。

go test -bench=.

運行獲取到的結果，具體數值取決于您的機器性能。

根據提供的基準測試結果，以下是各個字符串拼接方法的性能對比分析：

1. [BenchmarkStringSprintf](file:///Users/jie/Desktop/code/go/onego/xh02/add_test.go#L12-L20)（使用 fmt.Sprintf 拼接）：

   • 執行次數：88 次
   • 每次操作耗時：約 13,797,447 ns (13.8 ms)
   • 分析：性能最差，因為 fmt.Sprintf 在每次調用時都需要進行格式解析和內存分配，效率較低。

2. [BenchmarkStringAdd](file:///Users/jie/Desktop/code/go/onego/xh02/add_test.go#L23-L31)（使用 + 操作符拼接）：

   • 執行次數：99 次
   • 每次操作耗時：約 11,765,825 ns (11.8 ms)
   • 分析：比 fmt.Sprintf 快，但由于字符串是不可變類型，每次 + 操作都會創建新字符串并復制內容，性能依然有限。

3. [BenchmarkStringBuilder](file:///Users/jie/Desktop/code/go/onego/xh02/add_test.go#L34-L43)（使用 strings.Builder 拼接）：

   • 執行次數：9418 次
   • 每次操作耗時：約 123,530 ns (0.12 ms)
   • 分析：性能最優。strings.Builder 是專為高效字符串拼接設計的類型，內部使用 []byte 緩沖區，避免了頻繁的內存分配和復制。

總結：

• strings.Builder 明顯優于其他兩種方式，尤其在大量字符串拼接操作中表現最佳。
• 避免在循環中使用 fmt.Sprintf 或 + 進行字符串拼接，除非對性能要求不高。
• 推薦在性能敏感場景下優先使用 strings.Builder。