單元測試業務邏輯層

Question

我開始在我們公司介紹形式單元測試，因爲我們有一個越來越大的項目，在這個項目上另一個人會幫助我。所以我需要確定他所做的事情並沒有打破所有方面，反之亦然。

我也想介紹一個CI服務器，但這將是其他問題的主題。現在的問題是：我正在閱讀「單元測試的藝術」（這是一個建議的傑作！），作者強調的是單元測試與集成測試不同。對我來說這很明顯，如果我理解的很好，Business Logic單元測試應避免依賴數據庫連接等。首先：我是對的嗎？

所以，假設我是正確的（即當我單元測試我的BLL時，我應該存根數據庫），我該怎麼做呢？我讀過，有一些數據庫嘲笑的框架。我應該使用其中之一嗎？你使用哪個？

下一個問題：你真的認爲這是一個正確的方法嗎？我的意思是：在我的項目中，BL通過實體框架與數據庫連接。所以，例如，當我的BLL中的方法「UpdateItem」被調用時，它會執行一些操作，然後保存ObjectContext。這個ObjectContext是我需要在我的BL中刪除的實體框架依賴項。但是，我應該如何測試這種方法？我真的無法理解沒有測試DAL的單元測試BL層......你能舉個例子嗎？

非常感謝您的努力！

馬爾科

Answer 1

打樁數據庫是一項艱鉅的任務，我不覺得是值得的。我更喜歡有一個特殊的數據庫副本，以及適合單元測試的仔細準備的數據。

測試可以在測試結束時回退的事務中運行。這樣，單元測試數據庫永遠不會被測試修改，並始終保持已知狀態。我的博客上寫到Using Transactions for Unit Tests。這裏的示例代碼是針對linq-to-sql的，但同樣的方法也適用於實體框架。

Answer 2

是，

業務邏輯的單元測試應避免依賴於數據庫

你是對的。

我建議你：

• 使用一套單元測試業務層，使用存根的，而不是真正的數據庫調用。您可以用任何最適合您的數據庫（您擁有虛擬類或模擬庫）來存儲數據庫，前提是您已對數據庫組件進行了抽象。
• 使用一套集成的測試來測試實際的數據庫調用

單元測試和集成測試之間的主要區別是（也是唯一的！）： *單元測試的速度快，不需要任何配置 *集成測試可能很慢並且需要正確的配置（應該設置一個數據庫，並且應該有一個指向它的適當的連接字符串）。

我認爲這很好，因爲它允許您在更改代碼時經常運行業務單元測試。這一點很重要，因爲您得到的反饋速度非常快（通常在1-2秒內），所做的更改不會破壞任何內容。

偶爾，您可以運行集成測試（這將花費更長的時間）來驗證數據庫仍能正常工作。

此外，我建議你閱讀你提到的書。它認爲這是有關該主題的非常重要的信息來源。