ehlxr/gopl-zh.github.com
1
0
Fork 0
mirror of https://github.com/gopl-zh/gopl-zh.github.com.git synced 2025-10-23 06:51:44 +00:00
Code Issues Projects Releases Wiki Activity

ch11: fix code path

Browse Source
This commit is contained in:
chai2010
2016-01-20 23:00:49 +08:00
parent 0c1b9762d9
commit c683de9b81
4 changed files with 6 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
ch11/ch11-03.md
View File

@@ -7,13 +7,10 @@
這些幫助信息中語句的覆蓋率是最簡單和最廣泛使用的. 語句的覆蓋率是指在測試中至少被運行一次的代碼占總代碼數的比例. 在本節中, 我們使用 `go test` 中集成的測試覆蓋率工具, 來度量下面代碼的測試覆蓋率, 幫助我們識别測試和我們期望間的差距.
The code below is a table-driven test for the expression evaluator we built back in Chapter 7:
下面的代碼是一個表格驅動的測試, 用於測試第七章的表達式求值程序:
<u><i>gopl.io/ch7/eval</i></u>
```Go
gopl.io/ch7/eval
func TestCoverage(t *testing.T) {
var tests = []struct {
input string
@@ -102,5 +99,3 @@ $ go tool cover -html=c.out
不過兩個 panic 語句依然是紅色的. 這是沒有問題的, 因爲這兩個語句併不會被執行到.
實現 100% 的測試覆蓋率聽起來很好, 但是在具體實踐中通常是不可行的, 也不是值得推薦的做法. 因爲那隻能説明代碼被執行過而已, 併不意味着代碼是沒有BUG的; 因爲對於邏輯複雜的語句需要針對不同的輸入執行多次. 有一些語句, 例如上面的 panic 語句則永遠都不會被執行到. 另外, 還有一些隱晦的錯誤在現實中很少遇到也很難編寫對應的測試代碼. 測試從本質上來説是一個比較務實的工作, 編寫測試代碼和編寫應用代碼的成本對比是需要考慮的. 測試覆蓋率工具可以幫助我們快速識别測試薄弱的地方, 但是設計好的測試用例和編寫應用代碼一樣需要嚴密的思考.