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

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

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

1、沒有測試

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

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

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

3、編寫失敗的測試

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

4、擔心未實現(xiàn)測試

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

5、沒有很好地命名測試

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

6、讓測試做太多事情

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

• 《爐石傳說》邊境大哥德卡組代碼及玩法介紹
• 連接Elasticsearch服務器的Python代碼示例
• Spring事務操作后執(zhí)行代碼的解決方案
• 《魔獸爭霸3》秘籍黎明是什么
• 《魔獸爭霸3》秘籍立即戰(zhàn)敗是什么