为 .Net 选择模拟框架时应该考虑什么 [英] What should I consider when choosing a mocking framework for .Net
问题描述
有很多针对 .Net 的模拟框架.没有明确的赢家在各个方面都取代了其他人.领先的模拟框架也有许多不同的风格.
There are lots of mocking frameworks out there for .Net. There is no clear winner that has superseded the others in every way. The leading mocking frameworks also have many different styles of usage.
学习所有模拟框架所需的时间足以决定使用哪个是不合理的.我认为我们还没有达到可以谈论最好的模拟框架的阶段.那么我应该问关于项目和我自己的哪些问题，以帮助决定在特定情况下使用的最佳模拟框架?
The time it takes to learn all of the mocking frameworks well enough to decide which to use is unreasonable. I don’t believe that we have yet reached a stage that we can talk about the best mocking framework. So what questions should I be asking, both about the project, and about myself, to help decide on the best mocking framework to use, in a given case?
了解您选择当前使用的模拟框架的原因以及您是否仍然对这个选择感到满意也会很有用.
It would also be useful to know why you chose the mocking framework you are currently using and if you are still happy with that choice.
在比较模拟框架的风格时，是否有有用的词汇可供使用?
Is there a useful vocabulary to use when comparing the styles of mocking frameworks?
(注意:我将这个问题限制在.Net，因为Java没有属性或lambda表达式，所以我希望模拟框架对.Net比Java更好)
(Note: I have limited this question to .Net as Java does not have attributes or lambda expression, so I hope the mocking frameworks can be better for .Net then Java)
到目前为止的总结:
- 如果您需要模拟静态方法，或者没有虚拟方法，然后是唯一的合理的选择是 TypeMock，但它不是免费的，不会驱使你走向好的设计.
- Rhino Mocks 是一个很好的选择，如果你正在做 TDD，例如你的对象希望模拟实现接口.目前它似乎是市场领导者"
- 起订量 (introduction) 如果你是使用 .NET 3.5 Moq 可能在新项目中使用 Rhino Mocks
- If you need to mock static method, or none virtual methods then the only reasonable option is TypeMock, however it is not free and does not drive you towards a good design.
- Rhino Mocks is a very good option if you are doing TDD, .e.g the objects you wish to mock implement interfaces. At present it seems to be the "market leader"
- Moq (introduction) should be considered if you are using .NET 3.5 Moq may be gaining on Rhino Mocks for new projects
我从这个摘要中遗漏了什么?
What have I missed from this summary?
那么是什么驱动了 Rhino Mocks 和 起订量，如果您使用的是 .NET 3.5?
So what drives the choice between Rhino Mocks and Moq, if you are using .NET 3.5?
另见:
我应该考虑什么当为 .NET 选择依赖注入框架时?"可能也很有趣，因为它提出了问题的另一面".
"What should I consider when choosing a dependency injection framework for .NET?" may also be of interest as it asks the "other side" of the question.
推荐答案
那么我应该通过询问项目和我自己的哪些问题来帮助决定在特定情况下使用的最佳模拟框架?
关于该项目，您应该问的问题是:该项目是按照 SOLID 原则开发的，还是没有?这是一个松耦合、高内聚的项目吗?在构建项目时是否使用了良好的 OO 原则?是否使用了依赖注入容器?系统是否以按合同设计的方法进行编码(彻底利用接口)?
The questions you should be asking about the project is: Has the project been developed with the SOLID principles, or not? Is this a project that has loose coupling and high cohesion? Have good OO principles been utilized in building the project? Is a Dependency Injection container being utilized? Has the system been coded in a Design by Contract method (utilizing Interfaces thoroughly)?
如果您对这些问题的回答是肯定的，那么您可以使用像 RhinoMocks 这样的模拟框架，这就是某些人所说的有意见的"框架.RhinoMocks 和其他一些模拟框架对于如何设计系统以便模拟对象有非常强烈的意见.像 RhinoMocks 这样的框架希望您的项目以某种方式设计.当您以正确的方式构建代码(没有密封类、没有静态、大量使用接口、类上的虚拟方法等)时，使用 RhinoMocks 进行模拟肯定会容易得多.
If you answer yes to these questions, then you can utilize a mocking framework like RhinoMocks, which is what some would call an "opinionated" framework. RhinoMocks, and some other mocking frameworks, have very strong opinions about how a system should be designed in order for objects to be mocked. A framework like RhinoMocks expects your project to be designed a certain way. Mocking is certainly a lot easier with RhinoMocks when you've built your code the right way (no sealed classes, no statics, heavy use of interfaces, virtual on class methods, etc.)
如果您对这些问题的回答是否定的，或者如果您正在使用具有许多高度耦合类的遗留系统，那么您唯一的选择就是 TypeMock，它可以模拟任何东西.
If you answer no to those questions, or if you're working on a legacy system with a lot of highly coupled classes, then your only choice is going to be TypeMock, which can mock just about anything.
了解您选择当前使用的模拟框架的原因以及您是否仍然满意该选择也很有用.
我之所以选择 RhinoMocks，是因为当时(3 年多前)它显然是最成熟、功能最多的模拟框架.我一直在使用它，因为它已经进化了，这让我的生活变得更加轻松(AutoMocking 容器的出现是朝着效率迈出的一大步).
I chose RhinoMocks because at the time (3+ years ago) it was clearly the most mature mocking framework with the most features. I've stayed with it because it has evolved in away that makes my life much easier (the advent of the AutoMocking container being a gigantic step toward efficiency).
除了功能集和易用性之外，我喜欢 RhinoMocks 的地方在于它引导我在代码中进行更好的设计.我不是一个完美的程序员，我会在设计上犯错误.但是像 RhinoMocks 和 NHibernate 这样的工具可以帮助我做出更好的设计，因为当我确实犯了错误并创建了糟糕的设计时，使用这些工具会变得很痛苦.例如，如果您有一个糟糕的数据库设计，那么使用 NHibernate 会很痛苦.如果你有一个糟糕的类设计，不使用接口，不使用 IoC 等等，RhinoMocks 使用起来会非常痛苦.
What I like about RhinoMocks, other than the feature set and ease of use, is that it guides me toward a better design in my code. I am not a perfect programmer, and I am going to make mistakes in design. But tools like RhinoMocks and NHibernate help guide me toward a better design, because when I do make mistakes and create poor design, these tools become painful to work with. NHibernate, for instance, is painful to work with if you have a bad database design. RhinoMocks is very painful to work with if you have a poor class design, aren't using interfaces, aren't using IoC... etc.
我喜欢 RhinoMocks，因为它最终帮助我成为一个更好的开发人员，不仅仅是因为我正在测试我的代码，还因为我正在以更好的方式塑造我的代码 - 设计它.
I like RhinoMocks because it ultimately helps me be a better developer, and not just because I'm testing my code, but because I'm shaping my code - designing it - in a better manner.
这篇关于为 .Net 选择模拟框架时应该考虑什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
