沒有將產品正式錯誤列入測試
歡迎到原本部落格閱讀原文，認為翻譯有問題也歡迎討論。
測試的其中一個目的，是偵測程式碼是否退化，如同我們在測試錯誤功能提過的概念，大部分程式會有一個「極重要」（critical）的部分，大多數的錯誤從這邊出現。每當你修好一個錯誤時，你希望相同的錯誤不再出現。其中一個最好的辦法，就是針對這個錯誤寫測試，不管是單元測試、整合測試、或者兩個都寫。
進入產品程式碼的錯誤非常值得寫測試，因為：
- 錯誤能從這邊竄入產品程式碼，顯示這段這段程式碼缺乏測試
- 如果寫了對應測試，可以保證未來的產品不再出現相同的錯誤
當我看到擁有良好測試程式碼的團隊，卻不針對產品錯誤撰寫測試的時候，總是感到很驚訝。這些團隊遇到錯誤就只是修改程式碼，然後解決問題就好了。因為某些奇怪的理由，許多工程師似乎認為只有撰寫新功能的時候的測試是有價值的。
恰好相反。我甚至認為針對產品出現的錯誤撰寫測試，比起開發新功能時撰寫的測試要有價值。畢竟，寫新功能的時候你並不知道這個功能是否容易出錯，可能他恰好不屬於極重要的程式碼，所以不那麼常出錯。針對這些程式碼撰寫測試很好，但是價值有待商榷。
另一方面，針對已經出現的錯誤撰寫測試則非常有價值。這些測試不僅驗證了你現在的修改是正確的，也保證這部分程式碼未來不會出現相同錯誤，即使你重構了也一樣。
如果你接手了前人遺留的，完全沒有測試的程式碼，這也是首先可以從測試取得好處的地方。與其猜測這堆程式碼哪邊需要測試，你應該優先針對已經存在的錯誤修改並測試。過了一陣子之後，既然我們定義程式碼「極重要」的部分是會常常出錯的地方，那麼測試自然會覆蓋到這一些部分。Codepipes 測試標準的其中一項就是針對這部分。
唯一產品出現錯誤可以不寫測試的狀況是當錯誤完全來自環境設定而不是程式碼時。比方說， load balancer 的設置錯誤所導致的問題就不是任何單元或整合測試可以偵測的。
總之，如果你不確定該從哪邊開始撰寫測試，從已經偷溜進產品的臭蟲開始。