覆蓋
通常,測試覆蓋是一種用來發現程式碼庫中未被測試的程式碼的工具,因為正如Martin Fowler[2]所說,測試驅動開發是一種能夠幫助你實現良好測試的實用工具,但並不完美。基於這個原因,查詢程式碼庫中未被測試的部分最有效的方法無非是時常執行合適的測試工具程式,或自動生成報告,例如使用每日構建方式。
然而,第一種方式似乎顯得有點不負責任,而第二種涵蓋了過多的東西從而會影響測試質量[3]。更不用說花費在上下文轉化中的代價,擴充套件覆蓋需要測試你在幾天前或幾周前寫的程式碼。
因此,Paul Johnson建議在開發過程中儘早使用測試工具,定期的使用程式碼覆蓋測試程式[4]。但是,到底什麼時候算是儘早呢?對於第二種方法我認為最佳的時刻是在完成單元測試之前。因為這個時刻所有的單元測試都會被寫入,所有的重構也應該完成,此時進行快速覆蓋能夠檢查出程式碼被忽略的部分。同時,如果在這個過程中修復程式碼會花費最小的代價,因為這時並不涉及上下文切換。
當然,在上一段中最重要的一個詞就是“快”,這也就意味著這種方式只有在覆蓋資料能夠快速被收集、結果非常容易檢查的情況下才適用。幸運的是EclEmma可以無縫的整合在Ecelipse中,通過提供啟動配置,合適的快捷方式以及程式碼的高亮顯示能很好的滿足以上的要求,並不會給開發者增加程式碼處理的負擔。
EclEmma
在Eclipse中若干種快速執行測試用例的方法[5]。但EclEmma可以使用快捷鍵Ctrl+Shift+F11重新啟動最近一次的測試程式。由於測試驅動開發要求測試用例執行速度很快,其相關的測試資料收集也需要很快。這意味著能夠在測試過程中檢測單元測試的覆蓋真的很快。
一旦資料收集完成,覆蓋統計就會在結果中顯示出來。但是僅僅執行一個或幾個測試用例,整體的結果會很糟糕。最有趣的是程式碼編輯器中的高亮顯示:
高亮顯示
該圖片顯示了所謂的最好測試用例,所有的說明都和分支都被覆蓋了。但是這不足以說明全覆蓋對底層的測試一無所知[6]。唯一合理的結論是:如果程式碼編寫過程中考慮的詳盡周到,應該沒有明顯的未覆蓋盲區,該單元的開發可能宣佈完成。
但是,如果我們得到的結果如下圖所示,該模組一定沒有完成:
正如你所看到了的測試並沒有覆蓋所有的分支,而且完全遺漏了一個宣告,這意味著我們還有未完成的工作。最好的解決辦法就是新增一些新的測試消除這些盲區。但是,根據Brain Marick的說法,這些盲區可能意味著你的測試用例裡有更多的基礎問題,被稱為“忽略錯誤”[7]。所以,最好還是重新考慮一下測試用例。
有時你可能需要除了指令和分支計數器以外的方式度量測試結果。這種情況下,你只需要點選當前類中的報告檢視即可檢視各種覆蓋指標,具體如下圖所示:
結論
關於程式碼覆蓋以及如何解釋報告還有很多東西可講,我在這裡就不多說了。請大家參考文章註腳中提到的參考文獻。總結的說,全覆蓋是良好測試的一個必要但非充分條件。但值得注意的是,全覆蓋並不總是可以實現,或者因為其不合理的代價無法實現。所以要記住,不要過度的苛求全覆蓋,或者說再次引述Martin Fowler的話:我懷疑完美的東西,比如人們寫測試用例提高覆蓋數量,但卻並不知道他們在做什麼[2]。
使用最後提到的這種方法,通常使得專案的覆蓋率低於90%[8]。鑑於此,你的同事們也需要使用相同的模型和規則,至少在一段時間內,我的同事們是這樣做的。
- 1.軟體開發過程中的場景包括方法、開發技術、框架、類庫以及工具。
- 2.測試覆蓋Martin Fowler, 4/17/2012
- 3、參考Dashboards promote ingnorance Sriram Narayan,4/11/2011
- 4、測試及程式碼覆蓋 Paul Johnson 2002
- 5、參考Eclipse中高效的使用JUnit
- 6、為了說明這點,將產生全覆蓋測試用例中的斷言和驗證資訊註釋掉。這樣做通常不會影響測試報告,這時候測試用例已經沒有意義了。
- 7、Brian Marick寫的如何錯誤的使用了程式碼覆蓋
- 8、記住我們的指標取決於選定的標準,通常路徑比分支覆蓋小,分支覆蓋可以小於語句覆蓋。
相關閱讀
評論(1)