我正在采取婴儿步骤严格遵循我的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，那么你最终会惊讶于你以其他方式编程。