为什么我们需要像 Easymock 、 JMock 或 Mockito 这样的模拟框架？
我们在单元测试中使用手写存根，并且我正在探索我们的项目中是否需要 EasyMock 或 Mockito 等 Mock 框架。
我没有找到从手写存根切换到模拟框架的令人信服的理由。
任何人都可以回答为什么当人们已经使用手写的模拟/存根进行单元测试时会选择模拟框架。
谢谢
We use hand written stubs in our unit tests and I'm exploring the need for a Mock framework like EasyMock or Mockito in our project.
I do not find a compelling reason for switching to Mocking frameworks from hand written stubs.
Can anyone please answer why one would opt for mocking frameworks when they are already doing unit tests using hand written mocks/stubs.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
简单的答案是我们不需要它们。
我们也不需要其他现有的框架，但是使用 Mocking 框架让我们的生活更轻松。作为开发人员，我们可以花更多的时间来解决手头的问题，而不是创建或执行模拟框架可以做的事情。
我也完全一样。我为什么要费心去学习模拟框架呢？手写存根就可以了。
我想到了几点，主要是这样一个事实：过了一段时间，你的测试就会变得模糊不清。当使用手写存根时，您所指的就是测试扩展。换句话说，您可以将代码写入存根，或者根据发生的情况返回值。更不用说空间了。模拟框架只需几行代码就可以完成所有这些工作。 模拟框架
的好处是：
最大的好处是当您需要模拟对象时，必须手动编写代码来检查方法是否被调用、调用了多少次等等，这本身就是一个小任务。如果其他人已经这样做了，并创建了一个经过彻底测试、记录良好的框架，那么不使用它就没有意义。就像任何框架一样，没有它你也可以顺利进行，但有时使用正确的工具会让工作变得更容易。
The simple answer is we do not need them.
Nor do we need other existing frameworks, but using Mocking frameworks makes our lives easier. As developers we can spend more time on the problem at hand, rather than creating or carrying out what mocking frameworks can do.
I was exactly the same. Why should I bother learning a mocking framework? Hand written stubs do fine.
A few points come to mind, mainly the fact that after a while your tests become obscure with test stubs. What you are refering to when using hand written stubs are known as test extensions. You extend code to enable what mocking frameworks do. In other words you write code to stub, or return values depending on what happens. This takes time, and effort. Not to mention space. A mocking framework can do all this in a matter of lines.
The benefits of a mocking framework are:
The biggest benefit comes to when you require mock objects. Having to hand write code to check if a method was called, how many times and so forth is a mini task in itself. If someone else has done so, and created a throughly tested, well documented framework, it wouldn't make sense not to use it. Just like any framework, you can go along fine without it, but sometimes using the right tool makes the job a lot easier.
您可能想阅读 Martin Fowler 的模拟不是存根文章。基本区别是：
有些错误情况无法使用存根进行测试。另一方面，使用模拟的测试通常不太稳定。
虽然存根可以通过合理的努力手动编写，但模拟将需要更多的工作。一个好的模拟框架也可以使编写存根更快、更容易。
You might want to read Martin Fowler's Mocks Aren't Stubs article. The basic difference is this:
There are some error condition that cannot be tested for with stubs. On the other hand, tests using mocks are often much less stable.
While stubs can be written manually with reasonable effort, Mocks would require far more work. And a good mocking framework can make writing stubs faster and easier as well.
就像所有其他开发人员一样，我发现自己编写代码而不是使用现有的解决方案 - “不是在这里发明的”综合症。
您的问题表明您更喜欢编写需要伪造/模拟两次的类，而不是使用可以为您完成此操作的框架。使用模拟框架可以让您在更改伪造对象时无需编写、重构和更新手动模拟。
换句话说，使用模拟框架就像任何其他第 3 方库（例如 ORM）一样 - 其他人编写了代码，因此您不必这样做。
Just like every other developer I find myself writing code instead of using the existing solution - the "not invented here" syndrome.
Your question suggest that you prefer to write the classes you need to fake/mock twice instead of use a framework that would do that for you. Using a mocking framework frees you from needing to write, refactor and update your hand rolled mocks whenever you change the faked object.
In other words using a mocking framework is just like any other 3rd party library e.g. ORM - someone else wrote the code so you don't have to.
我以同样的方式开始（手工编写模拟），现在我几乎完全切换到 EasyMock。
我发现使用 EasyMock 通常既更快又更灵活。
通常，当我第一次需要模拟时，我可以使用 EasyMock 将其包含在几行代码中，而我需要手动实现所需的接口（很公平，这可以由像 IntelliJ 这样的 IDE 生成），然后添加必要的代码以产生所需的响应和/或允许感知对其调用的效果。
好吧，有人可能会说，这只是一次性成本。下次我可以愉快地重复使用手写的模拟......我发现情况往往并非如此。在另一个测试中，我可能需要模拟具有不同行为的同一类。例如，调用不同的方法，和/或期望不同的结果。一种特定情况是模拟预计在一个测试用例中抛出异常，但在另一个测试用例中不会抛出异常。很好，我可以向其中添加一些参数来动态控制行为。然后，对于下一个测试，更多的参数来控制更多的行为......所以我最终得到了一个更加复杂的模拟实现，这是对更多单元测试的依赖 - 也带来了无意中破坏旧测试的风险。
与此相反，使用 EasyMock，我可以为每个测试独立配置我的模拟。因此，该行为在单元测试代码本身内是明确控制和可见的，并且不存在副作用的风险。
更不用说，如果需要的话，使用 EasyMock 您可以验证所需的方法是否按所需的顺序调用（我时不时也会这样做）。手动实现这一点（尤其是以通用方式）会很麻烦，而且没有任何额外的好处。
I started the same way (writing mocks by hand) and by now I have almost completely switched over to EasyMock.
I find that using EasyMock is usually both faster and more flexible.
Typically the very first time I need a mock, I can have it in a couple of lines of code with EasyMock, whereas by hand I need to implement the needed interface (fair enough, this can be generated by an IDE like IntelliJ) and then add the necessary code to produce the needed response and/or to allow sensing the effects of calls to it.
Fine, one might say, that's a one-time cost only. The next time I can just reuse the hand written mock happily... I found that's often not the case. In another test I might need a mock of the same class with different behaviour. E.g. different methods are called, and/or different result is expected. A specific case is when the mock is expected to throw an exception in one test case, but not in another. Fine, I can add some parameters to it which control the behaviour dynamically. Then for the next test, some more parameters to control more behaviour... so I end up with an ever more complicated mock implementation, which is a dependency for ever more unit tests - posing also a risk of inadvertently breaking older tests.
As opposed to this, with EasyMock I can configure my mocks independently for each test. Thus the behaviour is explicitly controlled and visible within the unit test code itself, and there is no risk of side effects.
Not to mention that with EasyMock you can verify that the required methods are called in the required order, if you need to (and I do, every now and then). Implementing this by hand (especially in a generic fashion) would be quite pain in the neck, for no added benefit.
有时，以声明方式创建模拟可能更容易，并且它可以帮助您使用框架比手动更轻松地编写某些行为。另一个小优点可能是，通过使用模拟框架，您可以明确地了解模拟。
Sometimes it might be easier to create mocks in a declarative manner and it can help you write some sorts of behaviours easier using the framework than by hand. Another small advantage might be also that by using the mocking framework you are being explicit about mocking.