国际奥委会会解决我们的问题吗？答案

【问题标题】：Will IOC solve our problems?国际奥委会会解决我们的问题吗？
【发布时间】：2010-03-12 22:07:58
【问题描述】：

只是试图在棕地类型系统中实施单元测试。请注意，我对单元测试世界还比较陌生。当然，这将是一个渐进的迁移，因为痛苦的领域太多了。

我正在尝试解决的当前问题是，我们在 VB6 时代以及将我们的应用程序转换为 .Net 时遵循了许多不良做法。我们有很多共享/静态函数，它们调用其他共享函数，而那些调用其他函数等等。有时依赖项作为参数传入，有时它们只是在调用函数中更新。我已经指示我们的开发人员停止创建共享函数，而是创建实例成员，并且只在接口之外使用这些实例成员，但这并不能缓解当前的情况。因此，您必须为代码路径中的每个函数递归地在顶层传递每个依赖项，并且方法签名变得一团糟。

我希望这是 IOC 能够解决的问题。目前我们正在使用 NUnit/Moq，我开始研究 StructureMap。到目前为止，我了解您几乎告诉 StructureMap for x interface 我想默认为具体类 y：

ObjectFactory.Initialize(x=>{x.ForRequestType<IInterface>().TheDefaultIsConcreteType<MyClass>()});

然后到运行时：

var mytype = ObjectFactory.GetInstance<IInterface>();

IOC 容器将为您初始化正确的类型。尚不确定如何将假货换成混凝土类型，但希望这很简单。国际奥委会会再次解决我上面谈到的问题吗？是否有一个特定的 IOC 框架会比 StructureMap 做得更好，或者他们都可以处理这种情况。任何帮助将不胜感激。

【问题讨论】：

标签： .net unit-testing ioc-container

【解决方案1】：

差不多，但这不是灵丹妙药。

请注意，IOC 容器应设置在您的应用程序根目录中。不是临时的。否则，您将实施一个反模式的服务定位器。

按照您的生产代码的构造注入，让 IOC 容器解决您的依赖关系。对于单元测试，您只需对依赖项进行硬编码。这将允许您使用模拟对象（测试替身）。换句话说，IOC 与单元测试无关。

【讨论】：

感谢 Finglas 的回复。这一切到底是什么样的？它是否消除了每个方法调用中的所有依赖参数？在进行单元测试时，如何轻松地为每个依赖项传递假货？
实际上对 IoC 到底是什么感到困惑。就像您上面所说的，您不会将 IoC 仅用于生产代码的测试代码。您仍然使用构造函数注入，但您只使用 IoC，因此您不必坐在那里让任何使用您的类的人传入每个参数。帮助我理解 IoC 的是在 DnrTV 上观看 James Kovacs 的截屏视频，其中涉及他构建自己的简单 IoC 容器。很有意思！！嗯，我不知道在这种情况下 IoC 会提供多少帮助。依赖/初始化图无处不在。
您无法一击完成所有任务，但通过一些计划，您应该能够逐步完成。这可能意味着在中间阶段创建一些不太漂亮的代码，但不要灰心，这是可以做到的 :) 祝你好运！
@user - 你仍然有每个构造函数的参数。 IOC 容器意味着您将编写一小部分代码来连接您的依赖项。测试将与往常一样，手动连接依赖项以允许换入和换出测试替身。查看一些关于 IOC 的文章，我个人使用 Ninject。 DI 是一个需要掌握的更重要的概念，如果没有 DI，您会发现很难进行测试。

【解决方案2】：

IoC 在摆脱静态方法和避免依赖委托方面非常出色，因为每个类很容易显式声明所有依赖关系。

关于单元测试有两个阵营：

在 IOC 容器中插入 Mocks 作为依赖项的实例，您不想在特定情况下对其进行测试，并让容器照常解析。如果您想将多个类作为一个集成组件进行测试，这种方法尤其适用。
模拟您需要构建一个类的单个对象的所有实例，以手动测试和插入这些实例。如果您想坚持单独测试每个班级（您的单元是一个班级），这特别有效

【讨论】：