我們有一個相當大的系統（大約100萬行），它非常依賴實體框架6.這意味着我們的DbContext被傳遞並在任何地方使用。如何使遺留系統嚴重依賴實體框架更具可測性？
我們還有很多「單元」測試，它們使用的是實際的SQL Server數據庫。運行測試的每臺計算機都有一個專用數據庫，在運行每個測試之前，該數據庫將被擦除並設置所需的數據。
這當然是在速度，可維護性，易用性方面不理想的，等
我的最終目標是讓所有的單元測試（〜5K測試）不能用一個實際的數據庫，但某種模擬。我知道這個過程並不容易，但我也希望它儘可能不那麼痛苦。
如何讓我的測試更快，更多的單位範圍？
這裏只有一個選項，那就是製作一個內存系統。內存中不幸的一點是，它不能像實體框架那樣很好地融合。
實體框架的所有模擬都建議使用模擬數據庫完成，而您已經設置了模擬數據庫。
所以好消息是，你可以在你自己的記憶中做到這一點！壞消息是，你可以在記憶中自己做。
您將不得不創建實體框架的鏡像實現，該實現僅適用於內存中的一組信息。在許多方面，這與內存緩存系統中的事件驅動類似，您將在創建內存嘲諷自定義實現時獲得的好處是，您可以輕鬆地將其移植到支持緩存數據庫信息的位置，查詢該信息。
這將公開諸如事件驅動推送技術（SignalR）等實時數據的功能。這也需要很長時間。如果實現內存模擬實體框架所需的開發時間少於由於等待測試在模擬數據庫中完成而丟失的時間，那麼它可能是值得的。
實現一個提供程序看起來很複雜，但我想到了類似的東西，可能會更容易。我將使DbContext實現一個接口並在整個系統中使用此接口。在我們的測試中，我將用模擬替換DbContext的實例。聽起來可行嗎？ –
我們還有很多「單元」測試，它們使用的是實際的SQL Server數據庫。運行測試的每臺計算機都有一個專用數據庫，在運行每個測試之前，該數據庫將被擦除並設置所需的數據。
這當然是在速度，可維護性，易用性方面不理想的，等
我的最終目標是讓所有的單元測試（〜5K測試）不能用一個實際的數據庫，但某種模擬。我知道這個過程並不容易，但我也希望它儘可能不那麼痛苦。
我不同意你的結論。我建議你保留現有的專用測試數據庫，實際上我認爲使用實際數據庫進行測試是一個很好的主意，因爲它會顯示任何數據層問題，例如，如果有人對數據庫模式進行了更改，而沒有將其反映到EF實體類。 EF本身也經過了很好的測試，所以EF生成的類的代碼覆蓋率是我個人認爲的傻瓜差事，實體類和數據庫之間的脫節可能是事物可以（並且將會）去的第一領域錯誤。
我理解你使用這種方法時的性能問題，當然還有潛在的優化，比如在運行每個測試之前不要重置數據庫（可能讓測試假設數據庫之前處於已知的「良好狀態」開始），並且只在測試套件完成後才重置它。
我們測試中的性能瓶頸是在測試中對數據庫的調用。我希望我們的開發人員在破解測試時獲得快速反饋，而以目前的速度這是不可能的。 每個測試套件重置一次數據庫將會破壞我們大部分的測試（依靠乾淨的數據庫），並且需要我們手動修復所有這些測試。 –
*指導方針和想法* ...請閱讀適合這裏的問題類型的幫助。 –
「~1米線」 - 這不是「相當大」，這是*巨大*。 – Dai