測試代碼時你可能會犯的11個錯誤

7、沒有實(shí)際測試代碼

經(jīng)�？梢钥吹綔y試新手創(chuàng)建過于復(fù)雜的模型以及不能實(shí)際測試代碼的設(shè)置程序。他們可能會驗(yàn)證模擬代碼是否正確，或者模擬代碼是否和真正代碼做相同的事情，或沒有任何斷言而只是執(zhí)行代碼。這樣的“測試”都是白費(fèi)力氣，特別是如果它們的存在只是為了提高代碼覆蓋率水平的話。

8、擔(dān)心代碼覆蓋率

代碼覆蓋率的理念很崇高，但往往實(shí)際價值有限。知道運(yùn)行測試的時候有多少代碼被執(zhí)行應(yīng)該是有用的，但因?yàn)樗�不考慮正在執(zhí)行代碼的測試的質(zhì)量，因此就變得沒有意義。代碼覆蓋率在它數(shù)值非常高或非常低的時候，是挺博人眼球的。如果非常高，就表明，比起帶來的價值，過多的代碼可能正在被測試。非常低的代碼覆蓋率表明有可能代碼的測試不夠。因?yàn)檫@樣模棱兩可的意思，有的人就不知道單一片段的代碼是否應(yīng)該進(jìn)行測試。我用一個簡單的問題來明確這一點(diǎn)：代碼是否包含重大的復(fù)雜性？如果包含，那么你需要一些測試。如果沒有的話，你就不需要。測試屬性訪問器不過是浪費(fèi)時間。如果它們失敗的話，那么比起你正在寫的代碼，你的代碼體系出現(xiàn)了一些更根本的問題。如果你不用看一段代碼，就立即知道一切，那么它就不重大。這不僅適用于代碼，也適用于你寫代碼。如果我們在任意點(diǎn)重訪代碼，那么它就需要測試。如果在現(xiàn)有代碼中發(fā)現(xiàn)過bug，那就說明這一塊的代碼對其復(fù)雜性沒有進(jìn)行充分的測試。

9、著眼于一種類型的測試

一旦你開始測試，很容易只糾結(jié)于一種風(fēng)格的測試。這是一個錯誤。只用一種類型的測試，你就不能充分測試系統(tǒng)的所有部分。你需要單元測試來確認(rèn)代碼的各個組件是否能夠正確工作。你需要集成測試來確認(rèn)不同組件是否能夠協(xié)同工作。你需要自動化UI測試來驗(yàn)證軟件是否可以如預(yù)期使用。最后，你需要為任何不容易自動化的部分和探索性嘗試進(jìn)行手動測試。

10、著眼于短期測試

來自于測試的價值大多數(shù)會隨著時間的推移而獲得。測試不應(yīng)該只存在用于確認(rèn)事情是否正確寫入，而應(yīng)該隨著時間的推移繼續(xù)起作用，并且對于代碼庫做其他的改變。有回歸錯誤或新的異常，那么測試應(yīng)該重復(fù)運(yùn)行以盡早發(fā)現(xiàn)問題，這將意味著錯誤和異�？梢愿�快，更便宜和更容易被修復(fù)。沒有變化（人為錯誤）可自動和快速執(zhí)行的測試，是為什么編碼測試如此有價值的原因。

• 連接Elasticsearch服務(wù)器的Python代碼示例
• Spring事務(wù)操作后執(zhí)行代碼的解決方案
• 《魔獸爭霸3》秘籍黎明是什么
• 《魔獸爭霸3》秘籍立即戰(zhàn)敗是什么
• 計算機(jī)執(zhí)行匯編代碼的基本原理