ehlxr/gopl-zh.github.com
1
0
Fork 0
mirror of https://github.com/gopl-zh/gopl-zh.github.com.git synced 2024-11-04 21:43:42 +00:00
Code Issues Projects Releases Wiki Activity

ch11-3: review

Browse Source
This commit is contained in:
chai2010 2016-01-21 16:31:03 +08:00
parent 3d01e147f9
commit 41b4e72f7f
1 changed files with 14 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
ch11/ch11-03.md
View File

@ -1,13 +1,12 @@
## 11.3. 測試覆蓋率
就其性質而言，測試不可能是完整的。計算機科學家Edsger Dijkstra曾説過：“測試可以顯示存在缺陷，但是併不是説沒有BUG。”再多的測試也不能證明一個程序沒有BUG。在最好的情況下，測試可以增強我們的信心：代碼在我們測試的環境是可以正常工作的。
就其性質而言, 測試不可能是完整的. 計算機科學家 Edsger Dijkstra 曾説過: "測試可以顯示存在缺陷, 但是併不是説沒有BUG." 再多的測試也不能證明一個包沒有BUG. 在最好的情況下, 測試可以增強我們的信息, 包在我們測試的環境是可以正常工作的.
由測試驅動觸發運行到的被測試函數的代碼數目稱爲測試的覆蓋率。測試覆蓋率併不能量化——甚至連最簡單的動態程序也難以精確測量——但是可以啟發併幫助我們編寫的有效的測試代碼。
由測試驅動觸發運行到的被測試函數的代碼數目稱爲測試的覆蓋率. 測試覆蓋率併不能量化 — 甚至連最簡單的動態程序也難以精確測量 — 但是可以啟發併幫助我們編寫的有效的測試代碼.
這些幫助信息中語句的覆蓋率是最簡單和最廣泛使用的。語句的覆蓋率是指在測試中至少被運行一次的代碼占總代碼數的比例。在本節中，我們使用`go test`命令中集成的測試覆蓋率工具，來度量下面代碼的測試覆蓋率，幫助我們識别測試和我們期望間的差距。
這些幫助信息中語句的覆蓋率是最簡單和最廣泛使用的. 語句的覆蓋率是指在測試中至少被運行一次的代碼占總代碼數的比例. 在本節中, 我們使用 `go test` 中集成的測試覆蓋率工具, 來度量下面代碼的測試覆蓋率, 幫助我們識别測試和我們期望間的差距.
下面的代碼是一個表格驅動的測試, 用於測試第七章的表達式求值程序:
下面的代碼是一個表格驅動的測試，用於測試第七章的表達式求值程序：
<u><i>gopl.io/ch7/eval</i></u>
```Go
@ -46,7 +45,7 @@ func TestCoverage(t *testing.T) {
}
```
首先, 我們要確保所有的測試都正常通過:
首先，我們要確保所有的測試都正常通過：
```
$ go test -v -run=Coverage gopl.io/ch7/eval
@ -56,7 +55,7 @@ PASS
ok gopl.io/ch7/eval 0.011s
```
下面這個命令可以顯示測試覆蓋率工具的用法信息:
下面這個命令可以顯示測試覆蓋率工具的使用用法：
```
$ go tool cover
@ -69,20 +68,20 @@ Open a web browser displaying annotated source code:
...
```
`go tool` 命令運行Go工具鏈的底層可執行程序. 這些底層可執行程序放在 $GOROOT/pkg/tool/${GOOS}_${GOARCH} 目録. 因爲 `go build` 的原因, 我們很小直接調用這些底層工具.
`go tool`命令運行Go工具鏈的底層可執行程序。這些底層可執行程序放在$GOROOT/pkg/tool/${GOOS}_${GOARCH}目録。因爲有`go build`命令的原因，我們很少直接調用這些底層工具。
現在我們可以用 `-coverprofile` 標誌參數重新運行:
現在我們可以用`-coverprofile`標誌參數重新運行測試：
```
$ go test -run=Coverage -coverprofile=c.out gopl.io/ch7/eval
ok gopl.io/ch7/eval 0.032s coverage: 68.5% of statements
```
這個標誌參數通過插入生成鉤子代碼來統計覆蓋率數據. 也就是説, 在運行每個測試前, 它會脩改要測試代碼的副本, 在每個塊都會設置一個布爾標誌變量. 當被脩改後的被測試代碼運行退出時, 將統計日誌數據寫入 c.out 文件, 併打印一部分執行的語句的一個總結. (如果你需要的是摘要,使用 `go test -cover`.)
這個標誌參數通過在測試代碼中插入生成鉤子來統計覆蓋率數據。也就是説，在運行每個測試前，它會脩改要測試代碼的副本，在每個詞法塊都會設置一個布爾標誌變量。當被脩改後的被測試代碼運行退出時，將統計日誌數據寫入c.out文件，併打印一部分執行的語句的一個總結。（如果你需要的是摘要，使用`go test -cover`。）
如果使用了 `-covermode=count` 標誌參數, 那麽將在每個代碼塊插入一個計數器而不是布爾標誌量. 在統計結果中記録了每個塊的執行次數, 這可以用於衡量哪些是被頻繁執行的熱點代碼.
如果使用了`-covermode=count`標誌參數，那麽將在每個代碼塊插入一個計數器而不是布爾標誌量。在統計結果中記録了每個塊的執行次數，這可以用於衡量哪些是被頻繁執行的熱點代碼。
爲了收集數據, 我們運行了測試覆蓋率工具, 打印了測試日誌, 生成一個HTML報告, 然後在瀏覽器中打開(圖11.3).
爲了收集數據，我們運行了測試覆蓋率工具，打印了測試日誌，生成一個HTML報告，然後在瀏覽器中打開（圖11.3）。
```
$ go tool cover -html=c.out
@ -90,12 +89,12 @@ $ go tool cover -html=c.out
![](../images/ch11-03.png)
緑色的代碼塊被測試覆蓋到了, 紅色的則表示沒有被覆蓋到. 爲了清晰起見, 我們將的背景紅色文本的背景設置成了陰影效果. 我們可以馬上發現 unary 操作的 Eval 方法併沒有被執行到. 如果我們針對這部分未被覆蓋的代碼添加下面的測試, 然後重新運行上面的命令, 那麽我們將會看到那個紅色部分的代碼也變成緑色了:
緑色的代碼塊被測試覆蓋到了，紅色的則表示沒有被覆蓋到。爲了清晰起見，我們將的背景紅色文本的背景設置成了陰影效果。我們可以馬上發現unary操作的Eval方法併沒有被執行到。如果我們針對這部分未被覆蓋的代碼添加下面的測試用例，然後重新運行上面的命令，那麽我們將會看到那個紅色部分的代碼也變成緑色了：
```
{"-x * -x", eval.Env{"x": 2}, "4"}
```
不過兩個 panic 語句依然是紅色的. 這是沒有問題的, 因爲這兩個語句併不會被執行到.
不過兩個panic語句依然是紅色的。這是沒有問題的，因爲這兩個語句併不會被執行到。
實現 100% 的測試覆蓋率聽起來很好, 但是在具體實踐中通常是不可行的, 也不是值得推薦的做法. 因爲那隻能説明代碼被執行過而已, 併不意味着代碼是沒有BUG的; 因爲對於邏輯複雜的語句需要針對不同的輸入執行多次. 有一些語句, 例如上面的 panic 語句則永遠都不會被執行到. 另外, 還有一些隱晦的錯誤在現實中很少遇到也很難編寫對應的測試代碼. 測試從本質上來説是一個比較務實的工作, 編寫測試代碼和編寫應用代碼的成本對比是需要考慮的. 測試覆蓋率工具可以幫助我們快速識别測試薄弱的地方, 但是設計好的測試用例和編寫應用代碼一樣需要嚴密的思考.
實現100%的測試覆蓋率聽起來很美，但是在具體實踐中通常是不可行的，也不是值得推薦的做法。因爲那隻能説明代碼被執行過而已，併不意味着代碼就是沒有BUG的；因爲對於邏輯複雜的語句需要針對不同的輸入執行多次。有一些語句，例如上面的panic語句則永遠都不會被執行到。另外，還有一些隱晦的錯誤在現實中很少遇到也很難編寫對應的測試代碼。測試從本質上來説是一個比較務實的工作，編寫測試代碼和編寫應用代碼的成本對比是需要考慮的。測試覆蓋率工具可以幫助我們快速識别測試薄弱的地方，但是設計好的測試用例和編寫應用代碼一樣需要嚴密的思考。