測試程式碼時你會犯的 11 個錯誤

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

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

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

1.沒有測試

我們很容易毫無原因地掉入這個陷阱。從現在開始，制定計劃新增測試到你現在正在處理的程式碼中，並新增測試到將來的專案中。

2.沒有從專案一開始就啟動測試

我們很難再回過頭去新增測試，並且可能需要改變架構才能新增測試，這樣做最終將需要你花更長的時間才能產出可信任的程式碼。從一開始就在專案的生命週期新增測試可以節省時間和精力。

3.編寫失敗的測試

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

4.擔心未實現測試

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

5.沒有很好地命名測試

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

6.讓測試做太多事情

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

7.沒有實際測試程式碼

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

8.擔心程式碼覆蓋率

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

9.著眼於一種型別的測試

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

10.著眼於短期測試

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

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

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

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

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