單元測試存儲庫有沒有意義？實體框架4.1

Question

我一直在觀看各種視頻和閱讀各種博客，他們去了單元測試存儲庫。

最常見的模式是創建一個與真實界面相同的界面的僞造倉庫。然後假的使用內部字典或其他東西。

所以實際上你是單元測試fakerepository的邏輯，它永遠不會投入生產。

現在，您可以使用依賴注入通過使用某些IDBContext接口來注入模擬DBContext。然而，你只是測試每個存儲庫方法，實際上只是轉發到dbcontext（這是嘲笑）。

因此，除非在調用dbcontext之前每個存儲庫方法都有很多邏輯，那麼它看起來有點無意義？

我認爲將存儲庫測試作爲集成測試並實際讓它們擊中數據庫會更好嗎？

新的EF 4.1使這一切變得簡單，因爲它可以基於測試項目中的連接字符串即時創建數據庫，然後可以在使用dbcontext.Database方法運行測試之後將其刪除。

Answer 1

您的異議部分正確。它們的正確性取決於存儲庫的定義方式。

• 首先僞造或模擬存儲庫不是用於測試存儲庫本身，而是用於使用存儲庫測試圖層。
• 如果資源庫公開IQueryable並且上層可以構建linq-to-entities查詢，那麼模仿資源庫意味着測試不存在的邏輯。您需要集成測試並針對真正的測試數據庫運行查詢。您可以爲每個測試重新部署數據庫，這會使測試非常緩慢，或者您可以在事務中運行每個測試，並在測試完成時將其回滾。
• 如果存儲庫不公開IQueryable你仍然可以把它想象成一個黑盒子並嘲笑它。查詢邏輯將存儲在存儲庫中，並將通過集成測試單獨進行測試。

我會引用你關於repository itself and testing的其他答案的集合。

Answer 2

我見過的最好的方法是從夏普架構，他們使用SQLLite數據庫，在基於NHibernate映射信息的TestFixtureSetup中創建。

存儲庫測試然後使用這個內存數據庫。

從技術上講這仍然是集成測試所涉及的數據庫，但實際上，它囊括了所有盒爲一個單元測試，因爲：

1）數據庫是暫時的 - 沒有連接字符串CONFIGS擔心，也不是你需要一個完整的數據庫坐在某個服務器上供單元測試使用。

2）設置速度快，測試同樣如此，所有內存。 3）因爲它使用NHibernate映射信息來生成模式，所以你不必擔心保持單元測試設置與代碼更改同步。

http://wiki.sharparchitecture.net/default.aspx?AspxAutoDetectCookieSupport=1

它可能會使用與EF相同的方法。