我應該測試我的控制器（MVC）嗎？

Question

我一直在使用TDD幾個月，現在我想了解如何測試我的控制器（MVC）。

單元測試是通過測試每個功能的最小單元進行的。有時候，控制器不小。他們從模型中獲取數據，然後傳遞給視圖。

我該如何測試控制器？我應該模擬控制器的依賴關係嗎？

控制器測試是否被認爲是集成測試？

謝謝。

Answer 1

同樣的問題昨天問：

Does it make sense to test controllers

，在我看來 - 是的，它是有意義的測試控制器。您可以：

• 他們身後模擬服務，所以它更容易測試只是控制器本身
• 休假服務unmocked，做集成測試以及

Answer 2

我做TDD相當長的時間。我正在使用ASP.NET MVC進行TDD超過一年的時間。

我以規範的規則開始：「沒有沒有單元測試的代碼行」，所以我測試了一切 - 包括控制器。控制器必須經過測試，這是MVC框架的目標之一 - 讓這些東西成爲可測試的。

對於那些方法非常好的小應用程序。幾乎所有的邏輯都放在控制器內部，一切都很好地測試。

但是隻要我繼續使用MVC，我就開始改變主意了。我儘量保持控制器儘可能纖薄。理想情況下，只需將調用委託給某個業務對象幷包裝結果即可。其餘的是通過過濾器。

這對我來說也很好！我現在有了單獨實施/測試的業務對象，所以控制器就是集成點。沒有理由測試集成點，因爲它很小。

關於集成測試：我還沒有遇到這種情況，我真的需要這種情況。不要忘記，控制器總是依賴於由構造函數注入的抽象。只要你有'好'假設這些抽象如何工作，你創建適當的單元測試。當你失敗時，你只需糾正單元測試。

集成測試非常重要且有用，但我儘可能少地創建集成測試。

Answer 3

我採用與Alexander B.相同的方法來控制器，我的控制器很薄很笨。不過，我仍然爲它們編寫測試，以確保它們正確調用業務或服務對象並傳遞正確的參數。

這可能是我上週最終發現的一個實際bug最好的說明。我有一個控制器，允許管理員批准或拒絕來自用戶的請求，它有兩個視圖，未完成請求的列表視圖和每個請求的詳細信息視圖。兩種觀點都可以批准或否認。控制器調用的服務還有一些其他暴露的方法，其中包括更改請求狀態的方法...你可以看到這是怎麼回事。列表視圖稱爲批准或拒絕並觸發工作流的正確方法，細節視圖僅稱爲更改狀態方法，並未啓動任何進一步的工作流程。這是我的編碼錯誤，但對於我的生活，我無法看到它的歷史 - 工作流程在後臺線程中運行，並且我花了一週時間瀏覽那些線程，假設它在該部分中是錯誤的。

所以對我來說

• 由於作爲控制器的其他地方傳遞數據很快就需要測試。
• 如果需要測試（如果 有人去除哪些檢查？）

等

Answer 4

要開發單元測試爲您的控制器，自然的方式是你的控制器檢查模型的有效性模擬控制器依賴的接口（它控制的'事物'，我們稱它們爲IControllable s）。然後您可以驗證控制器是否按預期的方式操縱受控對象。

如果控制器與受控對象之間的交互較爲複雜，則專用集成測試可能有意義。例如，可能會有一系列的類實現IControllable - 這些實現中的每一個都可以很好地與控制器一起工作？也許多個不同IControllables將交互（使用相同的資源）？或者IControllables可能有棘手的方法來配置它們，影響它們的行爲？測試這種方法的一種方法是編寫一個可重用的測試套件，在其中抽取一系列可疑的實現或其組合。

最後但並非最不重要，TDD約驗收測試以及。因此，在進行TDD時，您還將進行高級別的端到端測試，以執行終端用戶可以識別的場景。最有可能的是，這些也會鍛鍊控制器 - 通過這種方式也可以測試控制器和（某些）類之間的正確集成。