MVC優勢

Question

我的應用程序已經具備了領域層單元測試，我想知道什麼是單元測試控制器的優點/缺點

和測試控制器時，應該寫什麼測試用例。

由於

Answer 1

這要看情況。

驗證，重定向，臨時消息等可能發生在控制器中。你可能會認爲這些操作應該像你的模型那樣進行測試。

另一方面，你應該瞄準'Fat Model, Skinny Controller'的心態。我傾向於確保我的控制器儘可能愚蠢。圍繞您關心的功能（硒，黃瓜等）進行一些端到端的測試，這些將強制您的控制器是正確的。假設我們正在開發一個列出一些項目的功能。如果此功能的端到端測試正常，則控制器正常。如果這個打破了，你會知道你已經引入了一個迴歸。結合這一點，我只有測試，檢查正確的意見呈現和正確的響應發生 - 重定向，JSON等...任何more testing on your controller和你有錯誤的地方的邏輯。

在Steve Sanderson的ASP.NET MVC2中，他對上述推理提出了一些優異的觀點。我完全推薦它。沒有這些簡單的控制器測試是我可以輕鬆打開您的代碼庫，做一個簡單的改變，並打破你的應用程序。只要正確的觀點/迴應發生，應用程序仍然會在功能上保持完好。

我應該補充一點，測試一個服務在控制器中被調用，正確的參數是如此的微不足道，而且你可以快速做到這一點，不管你是否間接測試你的控制器。我傾向於總體上贊成這種方法。所以你的問題的完整答案是肯定的，測試你的控制器;）

Answer 2

A'Pro的思想：

在要傳遞量化的數據或參數從控制器到視圖的情況。

在某些情況下，雖然我會認爲有限或罕見，但要測試控制器內部不受支持代碼測試覆蓋的內部邏輯。雖然可以認爲應該移動這些代碼段。

A「精讀」思想：

如果你的控制器測試沒有增加任何額外的代碼覆蓋率或者是重複的測試覆蓋率，它只是開銷和增加開發時間沒有好處。

Answer 3

儘管您應該始終努力將業務邏輯控制在控制器之外，但通常情況下，視圖模型的構建可能非常複雜以至於很容易進行測試。

例如，當通過多個選擇菜單顯示視圖時，這些菜單通過自定義視圖模型對數據庫進行復雜的linq查詢。這種邏輯不是業務邏輯，因此將其放入業務層似乎並不正確。另一方面，它需要進行測試。

編輯：爲了澄清，我不是說選擇查詢在你的看法。這將驗證MVC模式。我的意思是一個控制器，它執行這樣的查詢並用視圖顯示的結果構建複雜的自定義視圖模型。

Answer 4

有些東西，可能是在控制器的行動值得測試：即獲取視圖模型返回（如知名度，下拉列表值等）

重定向

1. UI邏輯（例如登錄的用戶將主頁重定向至其他網頁，而不是）
2. 驗證/警報

Answer 5

我發現測試控制器的問題之一是，在一些情況下，你必須模仿ASP.NET MVC遵循真正的執行鏈測試你的控制器。

例如，如果在OnExecuting方法中有代碼，則需要找到一種方法來在單元測試期間執行控制器中的實際操作方法時觸發該方法。