我正在採取嬰兒步驟嚴格遵循我的asp.net mvc項目的TDD和IOC方法。它非常痛苦，我很難直接思考。它就像我要失明，完全在黑暗中。測試驅動開發：asp.net mvc
它迫使我去學習C＃新特性。
神..我錯過了良好的舊拖放天，只是不停編碼離開，我想要的功能......但我知道，它不是爲我的項目的健康和我的職業生涯，作爲一個程序員好。
我只是去的信念，TDD和IOC是對我的MVC的健康。
你有什麼經驗？總是讀取的IoC肯定要走的路，但不是很醒目的「遠見」，但：
感謝
我在你的是同樣的情況至少花了幾個星期。我一直在閱讀和重新閱讀關於這個主題的文章，直到我覺得自己有一種處理方式，然後我開始重新編寫代碼的一些部分來使用DI。正如我這樣做，我開始注意到痛點，讓我意識到所有的地方，我沒有正確分離的問題，適當使用接口，否則使我的代碼模塊化和可重構。
TDD也是那些東西，是很難看到在第一的優勢之一。你認爲，「我已經知道我期望這種方法能做什麼，它做到了我所期望的，我爲什麼要測試它？」但是當你開始編寫一個單元測試時，你不得不用「我可以用這種方法實際得到什麼輸入」和「我會用它做什麼？」來考慮它。在某些情況下，你應該開始意識到你應該在方法開始時拋出特定類型的異常，而不是讓方法返回一個空集（消費者永遠不應該期待的）。或者你意識到你編寫這個類的方式使得不可能進行單元測試，並且實際上有更好的方法來設置它，從而降低複雜性。
最終你得到編寫代碼，並編寫單元測試好了很多，就是這麼快，它沒有大的痛苦可言。事實上，與編寫大註釋塊相比，您的單元測試可以提供更好的代碼預期行爲文檔。除此之外，我發現即使在我認爲我不可能寫錯的「簡單」方法上，單元測試也會發現大約50％的錯誤。
它花了很長時間和很多工作，但是我們的代碼質量更高，而且更易於維護，因爲DI和單元測試的做法迫使我們更好地分離代碼。
編輯
我還要提到的是，我們已經能夠利用依賴注入做的事情，本來是幾乎不可能了。例如，我剛剛做了這樣的事情，當Quartz工作採取行動時，他們顯示爲由特定「系統人員」爲特定域執行。如果我經常提到「HttpContext.Current」，或者甚至指向它的某個實用程序類，我將無法做到這一點。但是因爲我們使用DI，所以任何類都可以簡單地依賴於ISessionManager，IoC容器的內核可以決定它是應該使用基於HttpContext的實現還是使用特殊的「系統」會話管理器。
有一些技巧像這樣已經使我們的生活更加容易的。例如，我們不必告訴每個記錄器實例它在哪個類中，因爲DI框架可以自動告訴它它注入哪個類。我可以繼續下去。假設你以「正確的方式」做DI，那麼你最終會驚訝於你以其他方式編程。