iOS單元測試和UI測試全面解析(41)

運行您的所有測試(按下組合鍵Command+U)，然后打開報告導航器(按下組合鍵Command+8)。按執行時間先后選擇(By Time，見下圖)列表中最上面的一項，然后再選擇“Coverage”(覆蓋)選項卡。

你可以單擊如下圖展開的三角形圖標來觀察SearchViewController.swift文件中的函數列表︰

你可以把鼠標懸停在updateSearchResults(_:)方法附近的藍色的Coverage(覆蓋率)條上觀察到對應的覆蓋率為71.88%。

單擊該函數對應的箭頭按鈕來打開源文件，并定位到該函數。當你的鼠標移到右邊欄中的覆蓋率注釋上時，代碼段將突出顯示為綠色或紅色︰

覆蓋率注釋上的信息顯示出一個測試中命中每個代碼段的次數。注意，沒有被調用到的代碼段部分突出顯示為紅色。正如你所期望的，for循環運行3次，但沒有一次是沿著錯誤路徑執行的。為了提高此函數的代碼覆蓋率，你可以復制abbaData.json，然后修改它，使其會導致不同的錯誤——例如，將“results”更改為“result”來測試執行到打印語句print("Results key not found in dictionary")的情況。

100%覆蓋?

爭取實現100%的代碼覆蓋率你可知道應該付出怎樣的努力嗎?如果你使用谷歌搜索引擎搜索“100% unit test coverage”的話，你會搜索到有贊同的也有反對的等多種觀點，以及圍繞100%覆蓋率的大量爭論。其中，持反對看法的認為最后的10-15%并不重要——不值得為之付出努力;而持贊同看法的認為最后的10-15%極其重要——因為它很難測試。再使用谷歌搜索引擎搜索“hard to unit test bad design”可以找到頗有說服力的論據——無法驗證的代碼是一種更深層次的設計問題(https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters)。進一步的思考可能導致的結論是測試驅動開發(http://qualitycoding.org/tdd-sample-archives/)是軟件開發過程中必須要走的路。

原文轉自：http://mobile.51cto.com/iphone-535758.htm