太多的端到端測試？

Question

我真的通過這整個情況感到沮喪，而這是爲什麼：

我繼承了完全未經測試的遺留系統同步保持很多不同的客戶數據庫和一個主數據庫（使用不同的模式）。當系統給我時，系統只能部分完成，有很多缺陷會阻止它正常工作〜90％的時間。

該系統還具有六種不同的同步類型，每個同步不同的（有時是重疊的）表格，因爲數據庫可能相當大，所以客戶端可以根據其狀態優先考慮最重要的表格。

我開始進行一些端到端測試，在某些數據的本地設置一個主數據庫和多個客戶端數據庫，然後調用不同的同步方法，並以正確的格式驗證正確的數據顯示在正確的數據庫中。

因爲這個系統至少有一百種不同的方式，數據可以從一個數據庫移動到另一個數據庫，並且只有幾千行代碼，所以我只是不停地做越來越多的端到端結束測試，基本上每接收一個項目時存在的缺陷1-2個。我完成了16個單元測試（來自我添加的代碼的TDD'd）和113個端到端測試，其中許多測試直接基於以前的缺陷。

我完成了系統，它已經生產了好幾個月沒有發生。

最近，我們決定將客戶端數據庫轉換爲新的數據庫，並且當我使用新數據庫運行我的測試（它一直在CI服務器上每晚運行）時，約有100個失敗。 （當然，單元測試全部通過）。

我一直在修復失敗的端到端測試，坦率地說，大多數失敗的一個或兩個簡單的原因，（如新的數據庫四捨五入日期不同），但我感到沮喪的事實，我的測試是如此脆。雖然他們正確地失敗了，但我只需要一到兩個告訴我，而不是100. 問題是，單元測試沒有太多的代碼，因爲大部分代碼只是基於日期從一個表中選擇數據，然後從另一個數據庫中選擇相同的數據，將兩者合併，然後適當地插入/更新。

沒有這些測試，我無法完成這個系統，但維護它們的痛苦基本上是導致我這個問題的任何建議：有什麼建議我應該怎麼做/或者我可以做得更好？第一次寫這些端到端測試是否浪費了太多時間？我閱讀了Legacy Code，但我覺得那裏並沒有一個很好的答案，除了我感覺到的那種痛苦之外，「只是重構和編寫更多的單元測試」，我覺得它並不是很多的選擇做到這個系統的獨特性質是很少的代碼和大量的數據庫轉換。

Answer 1

您可以創建數據庫代理類，確保它們是與真實數據庫交談的唯一類。使用依賴注入來單元測試您的所有邏輯代碼，而無需與實際數據庫交談。創建儘可能少的端到端測試以確保代理可以正確讀取/寫入數據庫。

端到端測試通常本質上是脆弱的。所以儘可能少創建它們，如果你需要創建很多，你可以創建一個抽象層來設置fixtures和斷言。 複製測試用例與代碼中的重複一樣難以維護。

修改代碼有效合作是一個良好的開端，我建議的xUnit測試模式，這基本上是有很多很好的建議，包括與數據庫測試的一個部分單元測試的聖經。

編輯： TDD是所有關於隔離邏輯。我的意思是控制流程語句，正則表達式，算法，數學應該放在你的代理之外，你可以輕鬆地對它們進行單元測試。你有113個測試，這讓我懷疑有邏輯可以提取和單元測試。

如果您正在創建SQL命令，則可以使用Builder模式來驗證命令是否正確創建，並且如果您需要更改SQL方言，則只有一個地方可以進行更改。

使您的代碼可測試可能意味着你需要稍微積極重構。根據項目的重要性和壽命，困難的部分將決定有多少值得。