單元測試的數據庫代碼

Question

可能重複：
Unit testing on code that uses the Database

我剛開始使用單元測試，不知道被我的數據庫，使您的實際變化如何單元測試方法。最好的辦法是將它們放入交易中然後回滾，還是有更好的方法呢？

Answer 1

如果你想正確的測試覆蓋率，則需要兩種類型的測試：

• 單元測試該嘲笑你所有的實際數據的訪問。這些測試將不會acually寫入數據庫，但測試確實類的行爲（這對其他依賴調用哪個方法等）

• 系統測試（或集成測試）的檢查你的數據庫可以被訪問和修改。我會在這裏考慮兩種類型的測試：針對每個模型對象的簡單普通CRUD測試（創建/讀取/更新/刪除），以及針對您的實際方法的更復雜的系統測試以及您認爲有趣或有價值的測試。好的做法是讓每個測試都從一個空的（或「準備好測試」）數據庫開始，做好自己的工作，然後檢查數據庫的狀態。事務/回滾是實現這一目標的好方法。

Answer 2

一般的方法是有一種方法來模擬你的數據庫操作。以便您的單元測試不依賴於數據庫可用或處於特定狀態。也就是說，它也意味着設計有助於模擬您的數據層所需的隔離。單元測試和如何做得好是一個巨大的話題。看看谷歌Mock框架，並依賴注入一開始。

Answer 3

如果你想測試一個真正的數據庫，這將是更多的集成，然後單元測試。在交易中包裝測試可能是讓數據庫保持一致狀態的一個想法。 我們已經在基類中完成了這個工作，並且使用了TestInitialize和TestCleanup函數來確保總是發生這種情況。

但是，對真實數據庫進行測試肯定會使您遇到性能問題。因此，請確保從一開始就可以將數據庫訪問代碼與內存中運行的某些內容交換。我現在不知道哪個數據庫訪問代碼是您的目標，但設計模式如UnitOfWork和Repository可以幫助您隔離數據庫代碼並將其替換爲內存解決方案。

Answer 4

如果您未開發O/R映射器，則無需測試數據庫代碼。你不想測試ADO.NET方法，對吧？相反，您需要驗證是否使用正確的值調用了ADO.NET方法。

搜索Google存儲庫模式。您將使用CRUD方法創建一個實現IRepository接口並測試/模擬它。

Answer 5

對於單元測試，您需要模擬或存根數據訪問代碼，大多數情況下您擁有存儲庫接口，並且可以通過創建將數據存儲在內存中的具體存儲庫來存根，或者可以使用動態模擬框架來嘲笑它。

對於系統或集成測試，您需要在每個測試方法之前重新創建整個數據庫，以便在每次測試之前保持穩定的狀態。

Answer 6

根據以前的一些答案，如果你想測試你的數據訪問代碼，那麼你可能想要考慮模擬和系統/集成測試策略。但是，如果你想單元測試你的SQL對象（例如sprocs，視圖，表等中的約束） - 那麼有一些數據庫單元測試框架可能是有趣的（包括我有的書面）。

一些實施代碼中的SQL內測試，他人和使用MbUnit的/ NUnit的等

我已經寫了我如何處理一些與實例篇這一點 - 看到http://dbtestunit.wordpress.com/

其他可能的資源是使用：

http://www.simple-talk.com/sql/t-sql-programming/close-those-loopholes---testing-stored-procedures--/

http://tsqlt.org/articles/