2 回答

TA貢獻1851條經驗 獲得超3個贊
不要在代碼覆蓋率上花費太多時間。以某種方式務實。測試什么值得測試。提高您的測試質量,而不是數(shù)量。關于指標的一些旁注:100% 的線路覆蓋率不如高分支覆蓋率重要,獲得高分支覆蓋率可能會花費您很多時間,即使如此:您可能不需要采用每條可能的路線。PIT(突變測試)是一個有用的“工具”,它通過更改被測代碼來檢查您的測試實際上有多好。但是使用該信息作為指導,而不是作為實施更多測試的措施。不要夸張?。ㄒ苍S如果你正在開發(fā)一個庫,你不想再經常改變,或者你想讓它堅如磐石(并且你有空閑時間),你可以,否則我不會)
曾經有一段時間我非常準確地測試了一切。問題:一旦發(fā)生變化(例如:今天我們需要 X,明天它是 Y),您的許多測試就會失敗。然后需要大量返工。如果您測試最合適的,一旦需求發(fā)生顯著變化,您就可以專注于重要的事情,這應該花費更少的時間。
查看您提供的代碼,我可能會為每個 -Callable
實現(xiàn)編寫一個測試(類),以確保它們執(zhí)行我想要的操作(這可能會導致提取 -Callable
類作為副作用)。對于控制器和跑步者,我還不太確定......MyRunner
對我來說似乎已經過時了......但也許不是。所以可能我只會測試控制器......
關于模擬:我開始盡可能地省略模擬。大多數(shù)時候,我還添加了集成測試,我想知道系統(tǒng)作為一個整體如何運作以及它是否按預期工作。我看過很多測試,其中有很多模擬,通過更改任何代碼,沒有單元測試失敗,即使我認為有些測試應該失敗。我也見過很多單元測試,單元測試實際上看起來像集成測試,但到處都是模擬。那么模擬首先有什么幫助?單獨設置模擬可能花費了太多時間。但這又是我的看法。因此,盡管許多人喜歡測試金字塔有一個廣泛的單元測試底部,但我認為它更務實,并將一些測試移到集成測試“層”而不是使用大量模擬。最后它' 也是可用性和速度的問題。你希望你的測試快速給出結果,但你仍然希望結果最有價值(模擬只給出部分)。

TA貢獻1831條經驗 獲得超9個贊
編寫一個巨大的MyRunnableTest
測試類和編寫一個巨大的MyRunnable
生產類一樣具有代碼味道。由于您Callable
的每個s 都是不同的并且訪問不同的 I/O 資源,因此您希望分別測試它們中的每一個。實際的方法,例如文件系統(tǒng)操作的單元測試或嵌入式 H2 數(shù)據(jù)庫的集成測試,應根據(jù)具體情況選擇。
提取Callable
s 應該給你一個較小的MyRunnable
類。您現(xiàn)在可以拆分run()
成更小的方法或類并分別測試它們。此時,您可以模擬ExecutorService
.
您應該ExecutorService
在Controller
創(chuàng)建實際對象的類的測試中測試該對象。
覆蓋率只是一種幫助您衡量測試質量的工具。高覆蓋率本身并不是目標。如果你把它發(fā)揮到極致,你可以輕松地獲得 100% 的代碼覆蓋率,而不是測試中的單個斷言。
您可以應用測試驅動開發(fā)等其他技術和PIT 變異測試等工具來改進您的測試。但是,您應該首先使您的生產代碼易于測試。
添加回答
舉報