ehlxr/gopl-zh.github.com
1
0
Fork 0
mirror of https://github.com/gopl-zh/gopl-zh.github.com.git synced 2025-08-15 11:02:17 +00:00
Code Issues Projects Releases Wiki Activity

ch11-2: review

Browse Source
This commit is contained in:
chai2010
2016-01-21 14:46:10 +08:00
parent fd20d3df27
commit 3d01e147f9
7 changed files with 72 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
ch11/ch11-02-3.md
View File

@@ -1,15 +1,14 @@
### 11.2.3. 白盒測試
一種測試分類的方法是基於測試者是否需要了解被測試對象的內部工作原理。黑盒測試隻需要測試包公開的文檔和API行爲，內部實現對測試代碼是透明的。相反，白盒測試有訪問包內部函數和數據結構的權限，因此可以做到一下普通客戶端無法實現的測試。例如，一個白盒測試可以在每個操作之後檢測不變量的數據類型。（白盒測試隻是一個傳統的名稱，其實稱爲clear box測試會更準確。）
一個測試分類的方法是基於測試者是否需要了解被測試對象的內部工作原理. 黑盒測試隻需要測試包公開的文檔和API行爲, 內部實現對測試代碼是透明的. 相反, 白盒測試有訪問包內部函數和數據結構的權限, 因此可以做到一下普通客戶端無法實現的測試. 例如, 一個飽和測試可以在每個操作之後檢測不變量的數據類型. (白盒測試隻是一個傳統的名稱, 其實稱爲 clear box 會更準確.)
黑盒和白盒這兩種測試方法是互補的。黑盒測試一般更健壯，隨着軟件實現的完善測試代碼很少需要更新。它們可以幫助測試者了解眞是客戶的需求，也可以幫助發現API設計的一些不足之處。相反，白盒測試則可以對內部一些棘手的實現提供更多的測試覆蓋。
黑盒和白盒這兩種測試方法是互補的. 黑盒測試一般更健壯, 隨着軟件實現的完善測試代碼很少需要更新. 它們可以幫助測試者了解眞是客戶的需求, 可以幫助發現API設計的一些不足之處. 相反, 白盒測試則可以對內部一些棘手的實現提供更多的測試覆蓋.
我們已經看到兩種測試的例子。TestIsPalindrome測試僅僅使用導出的IsPalindrome函數，因此這是一個黑盒測試。TestEcho測試則調用了內部的echo函數，併且更新了內部的out包級變量，這兩個都是未導出的，因此這是白盒測試。
我們已經看到兩種測試的例子. TestIsPalindrome 測試僅僅使用導出的 IsPalindrome 函數, 因此它是一個黑盒測試. TestEcho 測試則調用了內部的 echo 函數, 併且更新了內部的 out 全局變量, 這兩個都是未導出的, 因此它是白盒測試.
當我們準備TestEcho測試的時候，我們脩改了echo函數使用包級的out變量作爲輸出對象，因此測試代碼可以用另一個實現代替標準輸出，這樣可以方便對比echo輸出的數據。使用類似的技術，我們可以將産品代碼的其他部分也替換爲一個容易測試的僞對象。使用僞對象的好處是我們可以方便配置，容易預測，更可靠，也更容易觀察。同時也可以避免一些不良的副作用，例如更新生産數據庫或信用卡消費行爲。
當我們開發TestEcho測試的時候, 我們脩改了 echo 函數使用包級的 out 作爲輸出對象, 因此測試代碼可以用另一個實現代替標準輸出, 這樣可以方便對比 echo 的輸出數據. 使用類似的技術, 我們可以將産品代碼的其他部分也替換爲一個容易測試的僞對象. 使用僞對象的好處是我們可以方便配置, 容易預測, 更可靠, 也更容易觀察. 同時也可以避免一些不良的副作用, 例如更新生産數據庫或信用卡消費行爲.
下面的代碼演示了爲用戶提供網絡存儲的web服務中的配額檢測邏輯. 當用戶使用了超過 90% 的存儲配額之後將發送提醒郵件.
下面的代碼演示了爲用戶提供網絡存儲的web服務中的配額檢測邏輯。當用戶使用了超過90%的存儲配額之後將發送提醒郵件。
<u><i>gopl.io/ch11/storage1</i></u>
```Go
@@ -49,7 +48,7 @@ func CheckQuota(username string) {
}
```
我們想測試這個代碼, 但是我們併不希望發送眞實的郵件. 因此我們將郵件處理邏輯放到一個私有的 notifyUser 函數.
我們想測試這個代碼，但是我們併不希望發送眞實的郵件。因此我們將郵件處理邏輯放到一個私有的notifyUser函數中。
<u><i>gopl.io/ch11/storage2</i></u>
```Go
@@ -74,7 +73,7 @@ func CheckQuota(username string) {
}
```
現在我們可以在測試中用僞郵件發送函數替代眞實的郵件發送函數. 它隻是簡單記録要通知的用戶和郵件的內容.
現在我們可以在測試中用僞郵件發送函數替代眞實的郵件發送函數。它隻是簡單記録要通知的用戶和郵件的內容。
```Go
package storage
@@ -108,7 +107,7 @@ func TestCheckQuotaNotifiesUser(t *testing.T) {
}
```
這里有一個問題: 當測試函數返迴後, CheckQuota 將不能正常工作, 因爲 notifyUsers 依然使用的是測試函數的僞發送郵件函數. (當更新全局對象的時候總會有這種風險.) 我們必須脩改測試代碼恢複 notifyUsers 原先的狀態以便後續其他的測試沒有影響, 要確保所有的執行路徑後都能恢複, 包括測試失敗或 panic 情形. 在這種情況下, 我們建議使用 defer 處理恢複的代碼.
這里有一個問題：當測試函數返迴後，CheckQuota將不能正常工作，因爲notifyUsers依然使用的是測試函數的僞發送郵件函數（當更新全局對象的時候總會有這種風險）。 我們必須脩改測試代碼恢複notifyUsers原先的狀態以便後續其他的測試沒有影響，要確保所有的執行路徑後都能恢複，包括測試失敗或panic異常的情形。在這種情況下，我們建議使用defer語句來延後執行處理恢複的代碼。
```Go
func TestCheckQuotaNotifiesUser(t *testing.T) {
@@ -125,6 +124,6 @@ func TestCheckQuotaNotifiesUser(t *testing.T) {
}
```
這種處理模式可以用來暫時保存和恢複所有的全局變量, 包括命令行標誌參數, 調試選項, 和優化參數; 安裝和移除導致生産代碼産生一些調試信息的鉤子函數; 還有有些誘導生産代碼進入某些重要狀態的改變, 比如 超時, 錯誤, 甚至是一些刻意製造的併發行爲.
這種處理模式可以用來暫時保存和恢複所有的全局變量，包括命令行標誌參數、調試選項和優化參數；安裝和移除導致生産代碼産生一些調試信息的鉤子函數；還有有些誘導生産代碼進入某些重要狀態的改變，比如超時、錯誤，甚至是一些刻意製造的併發行爲等因素。
以這種方式使用全局變量是安全的, 因爲 go test 併不會同時併發地執行多個測試.
以這種方式使用全局變量是安全的，因爲go test命令併不會同時併發地執行多個測試。