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

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

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

　　1.沒有測試

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

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

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

　　3.編寫失敗的測試

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

　　4.擔心未實作測試

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

　　5.沒有很好地命名測試

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

　　6.讓測試做太多事情

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

　　7.沒有實際測試代碼

　　經常可以看到測試新手建立過于複雜的模型以及不能實際測試代碼的設定程式。他們可能會驗證模拟代碼是否正确，或者模拟代碼是否和真正代碼做相同的事情，或沒有任何斷言而隻是執行代碼。這樣的“測試”都是白費力氣，特别是如果它們的存在隻是為了提高代碼覆寫率水準的話。

　　8.擔心代碼覆寫率

　　代碼覆寫率的理念很崇高，但往往實際價值有限。知道運作測試的時候有多少代碼被執行應該是有用的，但因為它不考慮正在執行代碼的測試的品質，是以就變得沒有意義。代碼覆寫率在它數值非常高或非常低的時候，是挺博人眼球的。如果非常高，就表明，比起帶來的價值，過多的代碼可能正在被測試。非常低的代碼覆寫率表明有可能代碼的測試不夠。因為這樣模棱兩可的意思，有的人就不知道單一片段的代碼是否應該進行測試。我用一個簡單的問題來明确這一點：代碼是否包含重大的複雜性?如果包含，那麼你需要一些測試。如果沒有的話，你就不需要。

測試屬性通路器不過是浪費時間。如果它們失敗的話，那麼比起你正在寫的代碼，你的代碼體系出現了一些更根本的問題。如果你不用看一段代碼，就立即知道一切，那麼它就不重要。這不僅适用于代碼，也适用于你寫代碼。如果我們在任意點重訪代碼，那麼它就需要測試。如果在現有代碼中發現過bug，那就說明這一塊的代碼對其複雜性沒有進行充分的測試。

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

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

　　10.着眼于短期測試

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

　　11.作為一個開發者，依靠于别人來運作(或編寫)測試

　　如果不運作，那麼測試幾乎沒有價值。如果測試不能被運作，那麼就可能遺漏bug。自動運作的測試(作為一個持續內建系統的一部分)是一個開始，但項目的任何一個人都應該能夠随時運作測試。如果需要特殊設定，機器，權限，或配置來運作測試，那麼這些将成為執行測試的壁壘。開發者需要能夠在檢查代碼之前就運作測試，是以他們需要能夠通路并有運作所有相關測試的權力。

　　代碼和測試應保持在同一個地方，并且所需的任何設定都應該寫好腳本。關于這個方面我見過的最壞的例子是一個做的很糟糕的項目，在這個項目中測試人員的子團隊定期取走開發人員正在處理的代碼副本，他們修改代碼以便他們能執行一系列測試，但這些測試是開發人員在特殊配置(無證)的機器上所無法通路的，然後測試人員再發送一個很大的郵件給所有的開發人員以說明他們找到的問題。這不僅是一個壞的測試方式，而且也是團隊工作的糟糕方式。不要這樣做。代碼能夠正确執行是專業開發人員的部分屬性。要保證代碼的準确性，方法是使用伴随它的适當測試。依靠其他人為你寫的代碼編寫測試和運作測試，不會幫助你成為一個專業的開發人員。

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

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