在.NET中,TypeMock Isolator和Microsoft Moles允许隔离任何类,属性或方法 - 无论是密封的,静态的,受保护的还是非虚拟的.所以在Moq或Rhino Mocks中不可能嘲笑,现在不再是这样了.
我总是对使用接口只是为了能够允许模拟的想法感到厌恶,否则只有具体的类存在.在这个视图中我并不孤单(见这里,这里和这里).在后者中暗示"现代"模拟框架不再需要用于测试或依赖注入的接口.
然而,虽然我不能说TypeMock Isolator,但我可以说在Microsoft Moles中使用Mocks非常慢.在单元测试中使用如下代码会使测试速度太慢而无法经常使用:
MFile.ReadAllLinesString = (s) => csvDataCorrectlyFormatted; MDirectoryInfo.AllInstances.GetFilesString = (di,fi) => fileInfoArray; MFileInfo.AllInstances.NameGet = (fi) => "Doesn't Matter";
我敢肯定,如果正在测试的方法被编程到接口或抽象基类(以便文件系统代码可以在各种包装中抽象出来),那么使用像Moq这样的框架来进行存根或模拟最终会更快.但是,我们又回到了基本上增加单元测试能力的生产代码复杂性的情况.
我倾向于认为Isolator和Moles只有在不能用传统的模拟框架模拟时才能使用.然而,为了测试,我仍然为添加生产代码复杂性这一概念而苦苦挣扎.
我很好奇社区其他人的想法.
更新10/06/10:通过说我为了测试而增加了生产代码复杂性的概念,我指的是在不需要时添加接口(或抽象类),例如,当使具体类非密封时,虚拟方法会做.后者仍然允许接缝进行测试.即使后来发现需要为多个实现使用接口,他们也不能从类中提取它吗?但除非出现这种需要,否则为什么不跟随YAGNI.
我全都采用SOLID原则,它们使程序的体系结构更易于维护.我不认为在每种情况下都需要虔诚地遵循这些原则.我认为咒语"它总是取决于",多次发挥作用.否则,即使只有一个实现,也会留下具有接口或抽象基类的每个具体类型.
最后,我不是说,因为Isolator和Moles允许人们在基于动态代理的框架中克服隔离限制,人们不应该将架构设计为可维护的.在许多情况下,SOLID原则是最好的,因此不需要隔离器或摩尔.这是接口仅用于我正在质疑的测试的情况.我也提出了关于速度的另一个观点.如果选择使用隔离器和摩尔,它似乎会带来速度惩罚.所以我当然不认为他们使基于动态代理的框架过时了.