我遇到的大多數(shù)開發(fā)人員都不怎么熱衷于測試。有些會去做測試，但大多數(shù)都不測試，不愿意測試，或者勉而為之。我喜歡測試，并且比起編寫新的代碼，愉快地花更多的時間在測試中。我認(rèn)為，正是因為專注于測試，我才可以花更少的時間來編寫新的代碼或修復(fù)bug，并且非常有成效。

如果你不確定要不要編寫測試或者并不常寫測試，那么，下面這些內(nèi)容將指導(dǎo)你往一個更好的方向發(fā)展。

1.沒有測試

我們很容易毫無原因地掉入這個陷阱。從現(xiàn)在開始，制定計劃添加測試到你現(xiàn)在正在處理的代碼中，并添加測試到將來的項目中。

2.沒有從項目一開始就啟動測試

我們很難再回過頭去添加測試，并且可能需要改變架構(gòu)才能添加測試，這樣做最終將需要你花更長的時間才能產(chǎn)出可信任的代碼。從一開始就在項目的生命周期添加測試可以節(jié)省時間和精力。

3.編寫失敗的測試

TDD方法的普及將紅—綠—重構(gòu)的理念帶到軟件測試世界。這個理念常常被誤認(rèn)為應(yīng)該“通過編寫一個失敗的測試開始”。其實并非如此。在寫代碼之前創(chuàng)建測試的目的是定義系統(tǒng)的正確行為應(yīng)該是什么。在許多情況下，它是一個失敗的測試（紅色表示），但它可能會通過一個非決定性的或未實現(xiàn)的測試來表示。

4.擔(dān)心未實現(xiàn)測試

軟件開發(fā)中的一個大問題就是，代碼和任何關(guān)于系統(tǒng)實際上應(yīng)該做什么的文檔之間的溝壑。通過擁有一個名稱中明確定義你最終想要實現(xiàn)的預(yù)期行為的測試，你將從測試中得到一定的價值，即使將怎么寫測試目前還不得知。

5.沒有很好地命名測試

命名軟件這件事出了名的很難做好，這同樣適用于測試。關(guān)于如何命名測試有幾種流行的約定。無論你使用哪一種都沒有關(guān)系，只要你能夠一貫使用，并準(zhǔn)確描述正在測試什么。

6.讓測試做太多事情

又長又復(fù)雜的名字通常說明了你想同時測試多件事情。單個測試應(yīng)該只測試一件事情。如果失敗了也應(yīng)該在代碼中注明是什么地方出了錯。你沒有必要為了知道代碼中出了什么問題而查看是哪部分測試失敗。這并不意味著你不應(yīng)該在測試中有多個斷言，但這些斷言應(yīng)該緊密相關(guān)。例如，一個查看訂單處理系統(tǒng)輸出，并確認(rèn)輸出中是否有一個單一項目以及它是否包含具體項目的測試，是ok的。但一個驗證相同系統(tǒng)的輸出的測試，既創(chuàng)建一個特定項目，又記錄到數(shù)據(jù)庫中，還發(fā)送確認(rèn)電子郵件，就不行了。

7.沒有實際測試代碼

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

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

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

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

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

10.著眼于短期測試

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

11.作為一個開發(fā)者，依靠于別人來運行（或編寫）測試

如果不運行，那么測試幾乎沒有價值。如果測試不能被運行，那么就可能遺漏bug。自動運行的測試（作為一個持續(xù)集成系統(tǒng)的一部分）是一個開始，但項目的任何一個人都應(yīng)該能夠隨時運行測試。如果需要特殊設(shè)置，機(jī)器，權(quán)限，或配置來運行測試，那么這些將成為執(zhí)行測試的壁壘。開發(fā)者需要能夠在檢查代碼之前就運行測試，因此他們需要能夠訪問并有運行所有相關(guān)測試的權(quán)力。代碼和測試應(yīng)保持在同一個地方，并且所需的任何設(shè)置都應(yīng)該寫好腳本。關(guān)于這個方面我見過的最壞的例子是一個做的很糟糕的項目，在這個項目中測試人員的子團(tuán)隊定期取走開發(fā)人員正在處理的代碼副本，他們修改代碼以便他們能執(zhí)行一系列測試，但這些測試是開發(fā)人員在特殊配置（無證）的機(jī)器上所無法訪問的，然后測試人員再發(fā)送一個很大的郵件給所有的開發(fā)人員以說明他們找到的問題。這不僅是一個壞的測試方式，而且也是團(tuán)隊工作的糟糕方式。不要這樣做。代碼能夠正確執(zhí)行是專業(yè)開發(fā)人員的部分屬性。要保證代碼的準(zhǔn)確性，方法是使用伴隨它的適當(dāng)測試。依靠其他人為你寫的代碼編寫測試和運行測試，不會幫助你成為一個專業(yè)的開發(fā)人員。

如果以上這些都不屬于你的情況，那么恭喜你！繼續(xù)保持開發(fā)穩(wěn)健又有價值的軟件。

如果上面有一些確實發(fā)生在你身上，那么是時候做一些改變了。

原文鏈接：http://www./shuoit/20160808/352732.html