測試代碼覆蓋工具的價值

Question

我們已經開始使用零件封面來跟蹤我們應用程序的測試代碼覆蓋範圍。海事組織是一個很好的工具，可以爲您的測試獲得總分，並突出顯示您可能對測試有點懶惰的測試領域，但今天我寫了一個測試，並意識到它沒有真正測試任何有用的東西，它只是增加了我的報道！

如果您是TDD，那麼您只需編寫代碼來通過測試，並且測試可以豐富地描述應用程序所需的所有功能。那麼在這種情況下，覆蓋分析仍然非常有價值嗎？

對於那些有覆蓋率的工具，你堅持如何保持100％的覆蓋率，你是否發現自己編寫的測試不是真的測試任何東西，只是爲了保持你的覆蓋面？這不是一個壞事？

Answer 1

覆蓋工具只能用於告訴您什麼不是已經過測試。你指出的場景說明了爲什麼你不能依靠它們向你展示哪些代碼已經過測試。如果覆蓋率爲100％，編寫測試是毫無意義的（正如您所懷疑的那樣），並且遊戲非常簡單，這並不是一個真正有用的指標。我曾經嘗試並保持在100％或接近100％，但我得出的結論與你所做的一樣。我正在寫測試，沒有真正測試任何東西，所以數字是正確的。使用這些工具來確定尚未測試的區域，然後編寫好的測試或接受這些代碼部分不重要的事實。

Answer 2

良好的理性化;）但我們畢竟是人類，我知道一個未經測試的方法或路徑並沒有投入生產，所以在夜間睡得更好。

Answer 3

如果你在做純粹的TDD，那麼代碼覆蓋的價值就會降低，因爲正如你所說，你只能從測試中編寫代碼，所以你應該在100％左右。但是，這可能是非常罕見的（有時不可能）純粹如此。

如果你不是純粹的TDD，100％是一個非常不切實際的目標。我通常會嘗試着選擇Roy Osherove的方法，只用邏輯來測試（比如不是直接的getter/setter或pass-through）。但是，越高越好，並且可以在這裏增加更多測試以增加覆蓋率。

Answer 4

我會扮演魔鬼的擁護者：如果增加你的覆蓋面意味着寫一個測試「沒有測試任何有用的東西」，那麼爲什麼那裏的代碼？對我來說，這將是一個刪除一些主線代碼的參數。

或者開發一個確實有用的測試。例如，你可能會認爲它對測試設置者和獲取者沒有用處。我也沒有。但是，這些方法應測試，而測試別的東西。否則，再次，他們爲什麼在那裏？

但你提出一個好的觀點，即覆蓋工具本身不應該是目的。特別是因爲他們不能告訴你你需要寫什麼代碼。

我已經在這裏更詳細了：http://www.kdgregory.com/index.php?page=junit.coverage