我们有一个控制器，它有一个接受另一个类对象的构造器。 例如，使用依赖注入对控制器进行单元测试
ABCController(IXyz obj){this.xyz = obj;}
现在，在单元测试，在实例化的电脑板，我们做这样的事情：
ABCController controller = new ABCController (new Xyz());
我们注入从单元测试项目，这之后我们的依赖能够测试控制器的所有方法。
现在最大的问题是，实例化控制器而不是提供/注入依赖的标准方式是什么？
我同意这就是存在大量嘲讽/测试框架的原因。但是我们是否需要采用新框架altogther才能避免注入依赖关系？或注入是最好的权衡，而不是完全采用新的框架？
请指教/澄清。
依赖注入的要点是你要注入依赖。所有的模拟框架都可以帮助您创建一个模拟对象来进行测试，而不需要自己用大量的样板代码创建新的测试对象。
使用容器或DI框架在您的测试IMO中创建控制器并不是一个好主意，因为您应该知道模拟对象以及您正在创建的内容。
所以你做得很对，但是使用Moq或Autofixture创建一个模拟IXyz来测试，而不是每次创建一个longhand。
有两个上下文来回答这个问题。首先，如何在测试时决定什么对象（嘲讽或存根）。其次，如何配置注入应用程序的依赖关系。
1.当测试
当测试（我的意思是单元测试居多），你经常要隔离正在从依赖测试的代码。这里有一个模拟框架（Moq，NSubstitute，Rhino Mocks等）派上用场。这些模拟一个依赖关系，并允许您进一步将测试中的代码与更改的依赖关系分开。
请注意，您可以为创建存根类实现，以便为每个需要注入的接口创建存根类实现。但是，在一个大型项目中维护可能会很乏味。但是，有些项目喜欢做这样的事情。但是，嘲笑框架通常提供的功能仅仅是存根。他们提供基于交互的断言，可以记录和回放发生在依赖关系上的操作。一旦记录完成，这些行为便可成为测试断言的基础。例如，一个特定的依赖是多少次叫，等
2.对于应用
在运行时，使用依赖注入的应用程序，需要一种方式来配置和解决依赖关系。依赖关系的应用程序配置为应用程序进程定义了“控制反转”。在这种情况下，通常会引入控制容器（Ninject，Castle Windsor，StructureMap等）的反转来帮助管理依赖项的配置和解决方案。
希望这会有所帮助。