2008-10-28 98 views
12

測試依賴於數據庫數據的API的最佳做法是什麼? 在作爲構建過程的一部分運行單元測試的「持續集成」環境中,我需要注意哪些問題?我的意思是你會將數據庫作爲構建腳本的一部分進行部署(可以運行安裝程序),還是應該使用硬編碼數據[使用MSTest Data Driven Unit Tests with XML]?數據驅動的單元測試

我知道我可以模擬業務邏輯層的數據層,但是如果我在DAL的SQL語句中遇到問題會怎麼樣?我確實需要打數據庫,對吧?

那麼......這是一個問題洪流:)......想法?

回答

5

儘可能地嘲笑代碼以避免完全觸擊數據庫,但在我看來,你認爲你需要在某個地方測試你的SQL。如果您確實編寫了測試數據庫,那麼避免頭痛的一個重要提示是確保您的設置將數據轉換爲已知狀態,而不是依賴已有合適的數據。

當然,從不測試您的實時數據庫!但不言而喻:)

+0

所以你簡單地刪除SetUp方法中的所有數據並執行手工定製的SQL作爲數據庫測試用例的第一步,對吧? – Kasper 2008-10-28 18:00:41

+0

@Kasper - 假設你已經建立了一個數據庫[理想情況是通過運行構建SQL腳本] ...當你有太多的測試裝置時,我相信最好的方法是先用種子數據設置數據庫。 – 2008-10-28 20:33:18

0

我做的一件事是創建靜態方法,返回已知狀態的測試數據。然後,我會使用「假」DAL來返回這些數據,就像我實際調用數據庫一樣。至於測試sql /存儲過程,我使用SQL Management Studio對其進行了測試。因人而異!

+0

如果SQL是動態生成的 - 例如不同的WHERE子句等等? – andygeers 2008-10-28 17:56:28

3

最好自動擦除測試數據庫,然後使用測試用具數據填充測試用具數據,測試用例數據將假定存在於所有需要連接到數據庫的測試中。數據庫需要在每次測試之前重新設置以進行適當的隔離 - 一個失敗的測試會導致錯誤的測試結果,如果您必須以特定的順序運行測試以獲得一致的結果,則會導致錯誤的測試失敗。

可以清除和填充工具(DBUnitDBUnit.NET,其他),或只是讓自己的實用工具類,做同樣的事情數據庫。正如你所說的,其他層應該與實際觸及數據庫的類充分分離,所以對測試中涉及的任何類型數據庫的需求僅限於測試運行一小部分代碼庫。您的數據庫訪問組件可以被模擬/存根以取決於它們的一切。

5

如前所述,在單元測試中使用模擬來模擬數據庫調用,除非您想無休止地調試測試和數據。測試sql語句意味着更多的integration test。運行它與單元測試分開,它們是2個不同的野獸。