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

　　如果你不確定要不要編寫測試或者并不常寫測試，那么，下面這些內容將指導你往一個更好的方向發展。

　　1.沒有測試

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

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

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

　　3.編寫失敗的測試

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

　　4.擔心未實現測試

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

　　5.沒有很好地命名測試

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

　　6.讓測試做太多事情

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

　　7.沒有實際測試代碼

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

　　8.擔心代碼覆蓋率

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

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

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

　　10.著眼于短期測試

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

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

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

　　如果以上這些都不屬于你的情況，那么恭喜你！繼續保持開發穩健又有價值的軟件。

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