只是尝试将单元测试实现为棕色场型系统。请注意,我对单元测试世界相对较新。它当然会逐渐迁移,因为有很多痛苦的地方。
我正在尝试解决的当前问题是我们在VB6时段以及将应用程序转换为.Net时遵循了许多不良做法。我们有很多共享/静态函数,它们调用其他共享函数,然后调用其他函数等等。有时依赖关系作为参数传递,有时它们只是在调用函数中新建。我已经指示我们的开发人员停止创建共享功能,而是创建实例成员,仅使用接口之外的那些实例成员,但这并不能缓解当前的情况。因此,您必须递归地传递代码路径中每个函数的顶层的每个依赖项,并且方法签名变得一团糟。
我希望这是国际奥委会将要解决的问题。目前我们正在使用NUnit / Moq,我开始研究StructureMap。到目前为止,我知道你几乎告诉StructureMap x接口我想默认为具体类y:
ObjectFactory.Initialize(x=>{x.ForRequestType<IInterface>().TheDefaultIsConcreteType<MyClass>()});
然后到运行时:
var mytype = ObjectFactory.GetInstance<IInterface>();
IOC容器将为您初始化正确的类型。还不确定如何将伪造品换成具体类型,但希望这很简单。国际奥委会将再次解决我上面谈到的问题吗?是否有一个特定的IOC框架可以比StructureMap做得更好,或者它们都可以处理这种情况。任何帮助将不胜感激。
答案 0 :(得分:4)
但实际上,它并不是银弹。
请注意,应在您的应用程序根目录中设置IOC容器。不是临时的。否则你将实现一个反模式的服务定位器。
遵循生产代码的构造注入,让IOC容器解析您的依赖项。对于单元测试,您只需对依赖项进行硬编码。这将允许您使用模拟对象(测试双打)。换句话说,IOC与单元测试无关。
答案 1 :(得分:1)
IoC非常适合摆脱静态方法并避免依赖委托,因为每个Class都很容易显式声明所有依赖项。
至于单元测试,有两个阵营: