應用CQRS - 是否需要對瘦讀層進行單元測試？

Question

鑑於實施CQRS的一些建議主張相當接近金屬查詢的實現，比如ADO.NET直接針對數據庫（或者基於LINQ的ORM）進行查詢，嘗試和單元測試他們？

我想知道它是否真的有必要？

我對此事的看法：

1. 附加架構複雜性提供了mockable「薄再現層」似乎相反意見的本質，以建築儀式降到最低。
2. 有效覆蓋用戶可能撰寫的每個查詢角度的單元測試數量都很可怕。

具體而言，我試圖CQRS出在ASP.NET MVC應用程序，並想知道是否打擾單元測試我的控制器操作方法，或者只是測試域模型。

非常感謝提前。

Answer 1

我傾向於同意你，單元測試這種代碼不是那麼有益。但是一些有用的測試仍然有一定的空間。

您必須執行一些驗證用戶的讀取查詢參數，如果是這樣，則測試無效的請求參數拋出合適的異常，並有效參數是允許的。

如果您使用的是ORM，我覺得成本/效益比太大，測試映射代碼。假設您的ORM已經過測試，映射中可能存在錯誤，但您很快就會發現並修復它們。

我也覺得它有用編寫一些集成測試（使用相同的測試框架），只是要確定我可以對數據庫的連接，和ORM配置不拋出任何異常的映射。你當然不想編寫查詢實際數據庫的單元測試。

Answer 2

我看過像這個單元測試過的東西的方式是讓單元測試在數據庫中創建一組東西，然後運行你的單元測試，然後清理創建的東西。

在過去的一個工作中，我看到使用數據結構很好地設置了對象及其關係。這是通過ORM運行來創建這些對象的，這些關係中的數據用於查詢，然後使用ORM刪除對象。爲了使單元測試更容易設置每個類指定的默認值，以在未覆蓋這些值的單元測試中使用。然後單元測試中的數據結構只需要指定非默認值，這就使得單元測試的設置更爲緊湊。

這些單元測試非常有用，並且在數據庫交互中遇到了一些錯誤。

Answer 3

在我的一個asp.net mvc應用程序中，我也應用了sqrc。但是，我們使用document database(mongodb)和每個命令或事件處理程序直接更新數據庫，而不是sql和'ADO.NET查詢'或'Linq'。

而且我爲一個命令/事件處理函數創建了一個測試。經過100％的單元測試，我知道我的域名在95％的情況下正常工作。 但是對於actions/controllers/ui我已經應用了ui測試（使用selenium）。

因此，似乎這兩個域（命令/事件處理程序和直接更新數據庫）的單元測試和ui測試它的'集成測試'。

我認爲你至少應該測試域部分，因爲你的所有邏輯封裝在命令/事件處理程序中。參考文獻：

僅供參考：我也開始從實體框架開始開發域部分，而不是通過存儲過程直接更新到數據庫中，但對文檔數據庫非常滿​​意。我嘗試了一些不同的文檔數據庫，但mongodb看起來對我來說最好。

Answer 4

正如你可能已經知道的單元測試較少關於代碼覆蓋率和防止錯誤，而不是關於良好的設計。儘管當我匆忙時，我經常跳過對讀取模型事件處理程序的測試，但毫無疑問，可能應該爲代碼應當TDD的所有原因完成此工作。

我還沒有進行單元測試我的HTTP操作（因爲我使用的南希不.NET MVC我沒有控制器本身）。

這些集成點和不傾向於包含很多邏輯，因爲大部分被封裝在命令處理程序和領域模型。

之所以我覺得這很容易不去測試這些，是因爲它們非常簡單而且非常重複，在讀取模型中對事件的非規範化幾乎沒有深入的思考。我的HTTP處理程序也是如此，它幾乎只是處理請求並向域發出命令，並有一些基本邏輯用於向客戶端返回響應。

在開發時，我經常在代碼中犯錯誤，如果我使用TDD，我可能會犯這些錯誤的次數要少得多，但這也需要更長的時間，這些錯誤往往很容易被發現和修復。

我的直覺告訴我，我應該仍然適用TDD這裏雖然，它仍然是一切都非常鬆耦合的，它不應該是很難寫的測試。如果您發現很難編寫可能表明控制器中存在代碼異味的測試。

Answer 5

根據我的經驗，如果你正在創建一個很好的非規範化閱讀模型，你將會做90％-99％的閱讀不要保證有他們周圍的單元測試。

我發現TDD CQRS應用程序最有效和最高效的方法是編寫集成測試，將命令推送到您的域中，然後使用查詢從數據庫中爲您的斷言取回數據。