單元測試，以防止生產

Question

我們最近有一個錯誤進入生產，我們添加了validates_presence_of到模型，但該列沒有爲更改之前創建的任何記錄，所以在舊數據上實例化模型的任何代碼都被破壞。

這似乎是一類只能在針對生產數據進行測試時才能捕獲的錯誤。

有沒有辦法創建單元測試來防範這些類型的問題？

Answer 1

當談論編寫代碼中不快樂路徑或案例的自動化測試（也稱爲否定測試）時，您最終會編寫測試以發現期望發生的事情。拿你的validates_presence_of的情況，你可以寫現在一個測試，驗證正確處理該列爲零的情況下，因爲你現在知道它可能發生。在出現問題之前編寫這些測試是棘手的部分，因爲您不知道必須這樣做。

如果你真的想避免這種情況發生之前，你可以考慮：

1. 測試對真實數據：獲得了真實數據庫的保持和運行功能測試和數據庫一致性檢查它。這種方法需要考慮的一些事情：

   • 如果您正在考慮作爲參考的數據庫有客戶數據，您可能想要匿名數據庫，爲了客戶的隱私。
   • 這種方法在開發循環中很難找到，因爲自動化設置和編排的成本很高。比如說，在進行大規模遷移之前，這種策略更適合一次性努力。
   • 正如我剛纔所說，你仍然會爲你寫的期望發生的事情的測試，但由於你增加你的數據集，有較高的可能性在一些意想不到的

2. 探索性測試絆倒：我知道你在你的問題中提到了單元測試，因爲你想讓這個過程自動化，但是在這些情況發生之前預防這些情況的另一個好方法就是將全部的大腦能量應用到意想不到的但可行的場景中，然後手動測試它們看看你的代碼是否支持這些場景（如果沒有，bug被捕獲，修補和編寫一個測試以確保該bug無法看到燈光）。

自動化方法可能會更好的規模會犯錯檢測而不是側面。在某些時候，我們必須接受軟件有缺陷，軟件開發並不是一個完美的過程，可以防止所有這些過程。這些錯誤很可能已經投入生產，所以我們儘量減少它們的影響。

我們仍然希望編寫測試以在發佈之前捕獲儘可能多的問題，以便到達我們用戶的問題非常罕見而且不危險。當發生這種情況時，良好的日誌記錄實踐，日誌聚合器，良好的錯誤監控和良好的警報方案將立即讓我們知道，並且在影響更多用戶或變得更糟之前，我們將能夠做出反應。

當執行canary releases時，此路徑可以變得更加穩定，anomaly detection模式應用於實時行爲數據，並且在事情開始出錯時自動回滾被編程。