我们真的需要隔离框架来创建存根吗？
我读过这个：http://martinfowler.com/articles/mocksArentStubs.html 我关于存根和模拟的概念很清楚。我了解隔离框架（如 moq、rhinomocks 等）创建模拟对象的需要。作为模拟，参与期望的实际验证。但为什么我们需要这些框架来创建存根呢？我宁愿推出一个手工创建的存根并将其用于各种固定装置。
I have read this: http://martinfowler.com/articles/mocksArentStubs.html
My concepts about a stub and a mock are clear. I understand the need of isolation frameworks like moq, rhinomocks and like to create a mock object. As mocks, participate in actual verfication of expectations. But why do we need these frameworks to create stubs. I would rather prefer rolling out a hand created stub and use it in various fixtures.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在决定手卷存根是更好的选择之前，您是否尝试过使用像 Rhino Mocks 这样的库一两天？
@chibacity：关于模拟库的整个想法是避免实现。如果我只需要设置单个属性的值，我不想创建接口的完整实现。 对我来说，调用这样的代码
似乎更简单。更不用说我只需要一个哑存根作为参数传递的情况，我不关心它会发生什么（所以不需要设置）。
这并不意味着您不应该为更复杂的场景推出自己的存根，但根据我的经验，这种情况很少见。
我的建议是学习如何使用一个好的模拟库（如 Rhino）及其所有小技巧，我敢打赌您很快就会学会欣赏它存在的原因。
Have you tried using a library like Rhino Mocks for a day or two before deciding that hand-rolled stubs is a better option?
@chibacity: The whole idea about mocking libraries is to avoid implementations. If I only need to set a single property's value, I don't want to create a whole implementation of an interface. Calling code like
seems much simpler to me. Not to mention situations where I only need a dumb stub to be passed as a parameter where I don't care what happens to it (so no set up is required).
This doesn't mean you shouldn't roll out your own stubs for more complex scenarios, but in my experience such cases are rare.
My recommendation is to learn how to use a good mocking library (like Rhino) with all its little tricks, my bet is that you'll soon learn to appreciate the reasons for its existence.
严格来说，不，您不需要隔离框架来创建存根。事实上，微软甚至有一个存根框架，仅< /em> 生成存根，而不是模拟。
我自己从未编写过隔离框架，但似乎一旦您进行了对象模拟，创建存根就会变得轻而易举。这可能是大多数/所有隔离框架包含存根对象的主要原因。
关于你的最后一句话（“我宁愿推出一个手工创建的存根并在各种固定装置中使用它”），你实际上在任何大型项目上尝试过吗？当然，也许您有一个带有返回可为 null bool 的单个方法的接口 - 您只需为该接口编写三个存根，这还不错。
但是，一旦您开始查看数十要存根的接口和类，跟踪所有不同的存根就会变得一团糟。如果您在多个测试中使用每个存根，那么您当然可以证明手写存根并将其放在一边是合理的；但是，当您仅使用一个特定存根一次或两次时，为了简单起见，将其保留为由框架直接生成的“匿名”存根要容易得多。
Strictly speaking, no, you do not need an isolation framework to create stubs. In fact, Microsoft even has a Stubs Framework that only generates stubs, not mocks.
I've never written an isolation framework myself, but it would seem that it once you have object mocking in place, stubs would be a breeze to create. That might be the main reason that most/all isolation frameworks include stub objects.
In regards to your last sentence ("I would rather prefer rolling out a hand created stub and use it in various fixtures"), have you actually tried that on any sizable project? Sure, maybe you have an interface with a single method that returns a nullable bool -- you only have to write three stubs for that interface, and that's not so bad.
But once you start looking at dozens of interfaces and classes to stub, it simply becomes a mess to keep track of all the different stubs. If you are using each stub in several tests, you can certainly justify hand-writing a stub and putting it aside; but when you only use one particular stub once or twice, it's much easier to keep it as an "anonymous" stub directly generated by the framework, for simplicity's sake.
使用模拟框架一段时间后，我发现我的代码设计呈现出完全不同的倾向。这种倾向似乎更多地针对交互风格。换句话说，我对消息和行为比状态更感兴趣。我的对象变成了服务，而不是像使用存根时那样有状态对象。通过存根，我最终将状态传递给其他对象。
对我来说，问题更多地变成了创建抽象层。我不得不质疑某些东西应该在某些层面上相互作用。这有助于创造“最后负责任的时刻”。所以我最终得到了有生产者和消费者的对象。两者之间的一切都只是消息通道。
我希望这有帮助。
After using mocking frameworks for a while, I have found that my code design takes on a totally different slant. This slant seems to be directed more in an interaction style. In other words, I become more interested in messages and behavior than state. My objects become services rather than stateful objects as would happen when using stubs. With stubs I end up passing state around to other objects.
The problem for me then becomes more of creating abstraction layers. I have to question whither something should be interacting at certain levels. This helps with creating that 'Last responsible Moment'. So I end up with objects that have producers and consumers. And everything in between is just message channels.
I hope this helps.