使用Soley接口来促进单元测试中的顽固和模拟现在已经过时了？

Question

在.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原则是最好的，因此不需要隔离器或摩尔。 这是接口仅用于我正在质疑的测试的情况。 我也提出了关于速度的另一个观点。 如果选择使用隔离器和摩尔，它似乎会带来速度惩罚。 所以我当然不认为他们使基于动态代理的框架过时了。

Answer 1

这确实是一个有趣的问题，我有时会从测试新手那里听到。 在我看来，Moles / Typemock与模拟框架并没有真正的可比性，它们肯定不是替代品。 以下是我的最佳论据：

• 虽然值得每一分钱，但Typemock的初始许可证费用相当可观（每个座位约800美元），为什么有些管理人员不愿投入这笔钱。 另一方面，Moles是免费的，但是需要相当多的工作来设置Moles装配并且带有一个非常奇怪的“API”，这很难学习 - 特别是如果你是一个全新的测试。
• Typemock和Moles不是严格意义上的“模拟框架” - 它们是某种类型的分析器，它们使用运行时工具。 因此，它们具有相当大的性能影响。 我没有具体数据，但根据我自己的经验，我估计仪表测试的速度要慢100-400％（Typemock似乎比MS Moles快）！ 对于包含数千个测试的大型测试电池，这本身可能是一个障碍。
• 最后一点，杀手论点：模拟框架不仅强迫您使用接口， 还强迫您在软件上应用高度分离和可维护的设计 （沿着SOLID ）。 - 并记住：这不是软件的初始编写，主要是它的成本，但它是维护！ - 使用Typemock或Moles，你基本上可以做任何你想做的事情，这真的是一件坏事，也是反对使用Typemock或Moles开发的主要论据。

结论：

• 如果你想用测试来覆盖一个棕色地带项目，而这个项目完全没有考虑到可测试性，那么你必须使用Typemock或Moles之一（在我看来，Typemock是更好的选择）。
• 如果你正在开始一个新项目（即你正在做一个绿地项目），那么使用一个模拟框架（我个人喜欢Moq，因为它简单）并使用MS Moles作为你不能拥有界面的补充for（例如.NET框架类型）。

即使是Typemock的首席开发人员Roy Osherove也是这样说的（希望他不会因此而与老板陷入困境）： 客户转向MOQ - 我很高兴

但有一个例外：如果从头开始学习测试驱动开发，即使是新代码也可能使用Typemock。 这样，您可以显着平滑TDD学习曲线......

托马斯

Answer 2

一点也不。 从纯粹的技术角度来看，接口并不是绝对必要的。 构建模拟的模拟框架的唯一要求是方法是虚拟的，并且类型具有可访问的构造函数。 当我知道某个特定类没有多个实现时，我会使用它。

我更喜欢使用基于Castle Dynamic Proxy的普通模拟框架来进行TDD。 这一切都与创建一个松散耦合的系统有适当的测试接缝。 那些测试接缝将来可能成为可扩展点。 通过模拟考虑提出的要求强化了良好的设计实践，从而导致编写更集中的类。

Answer 3

无论单元测试编码到接口有助于提供松散耦合的系统，允许您相对容易地滑入和滑出模块，可以将模块交换为另一个或某种配置。

除此之外，还有许多，包括我自己，可以说允许你模拟静态的TypeMock等允许不良做法。 其他人会说我们住在象牙塔里，TypeMock可以让你继续完成任务。 我会毫不犹豫地认为，根据您的观点和您想要实现的目标，这两者都是对与错。 我本人将继续使用接口和RhinoMock，NSubstitue或Moq。

正如您从这些帖子中看到的那样，从2008年到2010年， Good Design不是主观和设计与可测试 性 ，从评论中可以看出它仍然是一个令人讨厌的主题。

Answer 4

但是，我们又回到了基本上增加单元测试能力的生产代码复杂性的情况。

但这不是你做这件事的原因。 你这样做是因为否则代码对外部元素有很强的依赖性。 就像一个非常简单的邮件发件人的具体实现。

您将简单合同背后的外部功能隔离开来，这使得其余代码更简单/更复杂。 您非常清楚地看到代码具有的依赖关系，而不是隐藏在代码内部的依赖关系。

您现在有一个简单的机制来更改这些依赖项。 当你最终需要修改这些合同时，阻力就会减少，当代码在课堂内部的一个聊天对话中混淆时。

这在一个简单的stackoverflow问题的上下文中很难解释，特别是因为通常需要很长时间才能使好的设计概念真正陷入其中（如果他们这样做......）。 我建议在这里阅读有关SOLID的内容。

用TypeMock替换它就有它的位置。 测试未正确设计的遗留代码，以及可能少数其他方案。