測試真實存儲庫

Question

我已經設置了測試假存儲庫和使用假存儲庫的測試的單元測試。

但是如何測試命中數據庫的真實存儲庫？如果這留給了集成測試，那麼它似乎並未直接測試，並且可能會漏掉問題。

我在這裏錯過了什麼嗎？

Answer 1

那麼，集成測試只會測試數據在持久層中的數據持久性或檢索。如果您的存儲庫正在執行有關該數據的任何類型的邏輯（驗證，如果找不到對象則拋出異常等），可以通過僞造持久層返回的單元來進行單元測試（不管它是否返回查詢對象，返回代碼或其他東西）。您的集成測試將向您保證，代碼可以物理地持久/從持久性中檢索數據，就是這樣。任何類型的測試邏輯應該屬於單元測試。

然而，有時候，持久層本身可能存在邏輯（例如存儲過程）。這可能是爲了提高效率，也可能只是遺留代碼。這很難正確進行單元測試，因爲只能通過訪問數據庫來訪問邏輯。在這種情況下，儘可能嘗試將邏輯移動到您的代碼庫，這樣可以更輕鬆地進行測試。可能存在像這樣的場景的單元測試框架，但我不知道它們（僅僅是缺乏經驗）。

Answer 2

你可以設置一個真實的存儲庫，測試一個虛假的數據庫嗎？

無論你做什麼，這是集成測試，而不是單元測試。

Answer 3

我肯定會在合理的範圍內提出針對DAL的集成測試。

• 如果該方法簡單的從數據庫中檢索使用：

  我們不使用Repository模式本身（我們懊惱），但我們對類似的類（搜救）政策如下一個O/RM呼叫，不要測試它。

• 如果該方法使用O/RM的查詢構建功能，請對其進行測試。
• 如果該方法包含一個字符串（如列名），請對其進行測試。
• 如果該方法調用存儲過程，則對其進行測試。
• 如果該方法包含邏輯，請對其進行測試。但是儘量避免邏輯。
• 如果該方法繞過O/RM並使用原始SQL，請對其進行測試。但真的試圖避免這一點。

要點是你應該知道你的O/RM的作品（希望有測試），所以沒有理由去測試基本的CRUD行爲。

您肯定會需要一個「測試套件」 - 一個內存數據庫，一個本地文件支持的數據庫，可以檢入源代碼控制或（如果必須）共享數據庫。一些測試框架提供回滾工具來恢復數據庫狀態;如果您在同一測試中擊中了多個數據庫，或者（如果有嵌入式事務）（在某些情況下），請小心。

編輯：請注意，這些集成測試仍然會在「隔離」（保存爲數據庫）中測試您的存儲庫。所有其他單元測試將使用虛假的存儲庫。

Answer 4

我最近報道了一個非常類似的問題over here。

總結：測試具體的存儲庫實現是否有價值。如果你在實現中做了一些複雜的事情，那麼測試它可能是個好主意。如果您使用的ORM沒有自定義邏輯，那麼在該級別編寫測試可能沒有多大價值。