Question

只是尝试将单元测试实现为棕色场型系统。请注意，我对单元测试世界相对较新。它当然会逐渐迁移，因为有很多痛苦的地方。

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

我希望这是国际奥委会将要解决的问题。目前我们正在使用NUnit / Moq，我开始研究StructureMap。到目前为止，我知道你几乎告诉StructureMap x接口我想默认为具体类y：

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

然后到运行时：

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

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

Answer 1

但实际上，它并不是银弹。

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

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

Answer 2

IoC非常适合摆脱静态方法并避免依赖委托，因为每个Class都很容易显式声明所有依赖项。

至于单元测试，有两个阵营：

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

IOC会解决我们的问题吗？

2 个答案: