這裏的觀點非常值得探討, 所有的產品代碼就像是一項投資, 有些代碼的價值大, 因此需要寫更多的單元測試來提高測試覆蓋率. 另外有些代碼的單元測試編寫非常困難, 下面的一些因素可以用來幫助我們理解每個單元測試的價值:
1.代碼被用的次數和它的價值成正比.
2.被依賴程度決定測試價值. 如果其他代碼嚴重依賴被測試代碼, 那麼對應的測試價值大, 如果被測試代碼嚴重依賴其他代碼, 那麼這個代碼將難以測試. 而且不易於發現問題.
3.對I/O(網絡, DB, 文件)依賴的代碼難以測試, 需要使用mock技術, 而mock代碼工作量大, 維護成本高
4.多線程代碼更難以測試.
5.代碼越複雜越需要測試.
6.被更多人所熟識的代碼, 測試更容易. 因爲問題將會被更快的發現和處理.
單元測試另外一個關注點就是維護問題, 這時應該將我們的每個單元測試看成一支股票, 有些股票會不斷增值, 需要長期持有. 單元測試也是這樣. 每個單元測試都有一個初始價格(上市價格). 如果通過單元測試發現代碼改動產生了一個bug或者測試跑出了一個bug, 那麼這個測試的價值將增加. 而從來沒有幫助我們發現bug的測試價值則下降. 隨着業務的發展, 需要對代碼和測試進行重構, 這種情況下單元測試的價格不變.
但對單元測試的各項值的計算屬於機器學習的範疇, 這裏不做討論.
參考原文:[url]http://www.javacodegeeks.com/2012/01/effective-unit-testing-not-all-code-is.html[/url]
1.代碼被用的次數和它的價值成正比.
2.被依賴程度決定測試價值. 如果其他代碼嚴重依賴被測試代碼, 那麼對應的測試價值大, 如果被測試代碼嚴重依賴其他代碼, 那麼這個代碼將難以測試. 而且不易於發現問題.
3.對I/O(網絡, DB, 文件)依賴的代碼難以測試, 需要使用mock技術, 而mock代碼工作量大, 維護成本高
4.多線程代碼更難以測試.
5.代碼越複雜越需要測試.
6.被更多人所熟識的代碼, 測試更容易. 因爲問題將會被更快的發現和處理.
單元測試另外一個關注點就是維護問題, 這時應該將我們的每個單元測試看成一支股票, 有些股票會不斷增值, 需要長期持有. 單元測試也是這樣. 每個單元測試都有一個初始價格(上市價格). 如果通過單元測試發現代碼改動產生了一個bug或者測試跑出了一個bug, 那麼這個測試的價值將增加. 而從來沒有幫助我們發現bug的測試價值則下降. 隨着業務的發展, 需要對代碼和測試進行重構, 這種情況下單元測試的價格不變.
但對單元測試的各項值的計算屬於機器學習的範疇, 這裏不做討論.
參考原文:[url]http://www.javacodegeeks.com/2012/01/effective-unit-testing-not-all-code-is.html[/url]
