使用Soley接口来促进单元测试中的顽固和模拟现在已经过时了？ [英] Are Using Interfaces Soley to Facilitate Stubing and Mocking in Unit Tests Now Obsolete?

问题描述

在.NET中，TypeMock Isolator和Microsoft Moles允许隔离任何类，属性或方法 - 无论是密封的，静态的，受保护的还是非虚拟的。所以在Moq或Rhino Mocks中不可能嘲笑，现在不再是这样了。

In .NET, TypeMock Isolator and Microsoft Moles allow one to isolate any class, property, or method - be it sealed, static, protected or non-virtual. So what was impossible to mock in Moq or Rhino Mocks, now no longer is the case.

我总是对使用接口的想法感到厌恶能够允许嘲笑，否则只有具体的类存在。在这种观点中，我并不孤单（参见此处， 此处，这里）。在后者中暗示现代模拟框架不再需要用于测试或依赖注入的接口。

I've always had some aversion with the idea of using an interface merely to be able to allow for mocking, when otherwise just the concrete class would exist. I'm not alone in this view (see here, here, and here). In the later it's implied that 'modern' mocking frameworks no longer need interfaces for testing or dependency injection.

然而，虽然我不能代表TypeMock Isolator，但我可以说在Microsoft Moles中使用Mocks非常慢。在单元测试中使用如下代码会使测试速度太慢而无法经常使用：

However, while I can't speak for TypeMock Isolator, I can say that using Mocks in Microsoft Moles is extremely slow. Having code like the following in unit tests makes the speed of the test too slow to be used often:

MFile.ReadAllLinesString = (s) => csvDataCorrectlyFormatted;
MDirectoryInfo.AllInstances.GetFilesString = (di,fi) => fileInfoArray;
MFileInfo.AllInstances.NameGet = (fi) => "Doesn't Matter";

我确定如果被测试的方法被编程为接口或抽象基类（所以文件系统代码可以在各种包装中抽象出来，使用像Moq这样的框架进行存根或模拟最终会更快。但后来我们又回到了基本上能够进行单元测试的生产代码复杂性的情况。

I'm sure that if the method being tested was programmed to an interface or abstract base class (so that the file system code could be abstracted away in a wrapper of sorts) that using frameworks like Moq for stubbing or mocking would end up being faster. But then we are back to the situation of having added production code complexity for basically the ability to unit test.

我倾向于认为Isolator和Moles应该只当一个人不能用传统的模拟框架嘲笑时使用。然而，为了测试，我仍然为添加生产代码复杂性这一概念而苦苦挣扎。

I'm leaning to the opinion that Isolator and Moles should only be used when one can't mock with traditional mocking frameworks. Yet, I still struggle with notion of having added production code complexity for the sake of testing.

我很好奇社区其他人的想法。

I'm curious what the rest of the community thinks.

UPDATE 10/06 / 10：通过说我为了测试而增加了生产代码复杂性的概念，我指的是在不需要时添加接口（或抽象类），例如因为在使具体类非密封时，虚拟方法会这样做。后者仍然允许接缝进行测试。即使后来发现需要为多个实现使用接口，它们是否无法从类中提取它？但除非出现这种需要，为什么不遵循 YAGNI 。

UPDATE 10/06/10: By saying I struggle with the notion of having added production code complexity for the the sake of testing, I'm referring to the adding an interface (or abstract class even) when otherwise one isn't needed, such as when making the concrete class non-sealed and methods virtual would do. The latter still allows seams for testing. Even if later one finds the need to use an interface for multiple implementations, couldn't they extract it from the class? But unless that need arises, why not follow YAGNI.

我完全支持SOLID原则，它们使程序的体系结构更易于维护。我不认为在每种情况下都需要虔诚地遵循这些原则。我认为口头禅，它总是取决于，多次发挥作用。否则，每个具有接口或抽象基类的具体类型都会留下，即使只有一个实现。

I'm all for the SOLID principles where they make the architecture of a program easier to maintain. I don't think these principles need to be followed religiously in every case. I think the mantra, "It always depends", comes into play many times. Otherwise, one is left with every concrete type having an interface or abstract base class, even when there will be only one implementation.

最后，我不是这样说的，因为Isolator和Moles允许人们在基于动态代理的框架中克服隔离限制，人们不应该将架构设计为可维护的。在许多情况下，SOLID原则是最好的，因此不需要隔离器或摩尔。这是接口仅用于我正在质疑的测试的情况。我也提出了关于速度的另一个观点。如果选择使用隔离器和摩尔，它似乎会带来速度惩罚。所以我当然不认为它们会使基于动态代理的框架过时。

Lastly, I'm not saying that because Isolator and Moles allows one to get around isolation limitations in dynamic-proxy-based frameworks that one shouldn't still design architecture to be maintainable. In many cases, the SOLID principles are what is best, and thus Isolator or Moles wouldn't be needed. It's the cases where the interface is used solely for testing that I am questioning. I'm bringing up another side point about speed too. If one chooses to use Isolator and Moles it appears to bring a speed penalty. So I certainly don't think that they make dynamic-proxy-based frameworks obsolete.

推荐答案

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

Not at all. From a purely technical point of view the interfaces are not strictly necessary. The only requirement for a mocking framework to construct a mock is that a method is virtual and the type has an accessible constructor. I utilize it quite a bit when I know that a particular class will not have multiple implementations.

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

I prefer doing TDD with a normal Castle Dynamic Proxy based mocking framework. It is all about creating a loosely coupled system with appropriately placed testing seams. Those testing seams could in future become extensibility points. The requirements placed by mocking considerations reinforce good design practices, causing more focused classes to be written.

这篇关于使用Soley接口来促进单元测试中的顽固和模拟现在已经过时了？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！