问题描述
一种思考方式是:如果我们关心代码的设计，那么EasyMock是更好的选择，因为它通过期望的概念为您提供反馈.
One way of thinking about this is: if we care about the design of the code then EasyMock is the better choice as it gives feedback to you by its concept of expectations.
如果我们关心测试的可维护性(易于阅读，编写并且具有较少的易碎测试，且不受更改的影响较大)，那么Mockito似乎是一个更好的选择.
If we care about the maintainability of tests (easier to read, write and having less brittle tests which are not affected much by change), then Mockito seems a better choice.
我的问题是:
- 如果您在大型项目中使用过EasyMock，是否发现测试难以维护?
- Mockito的局限性(除了内部测试)?
推荐答案
我是EasyMock开发人员，所以有点偏心，但是我当然在大型项目中使用过EasyMock.
I'm an EasyMock developer so a bit partial but of course I've used EasyMock on large scale projects.
我的观点是，EasyMock测试确实有时会中断一次. EasyMock会强制您完整记录您的期望.这需要一些纪律.您应该真正记录预期的结果，而不是测试方法当前需要的内容.例如，如果在模拟中调用一个方法的时间无关紧要，请不要担心使用andStubReturn.另外，如果您不关心参数，请使用anyObject()等.在TDD中进行思考可以对此有所帮助.
My opinion is that EasyMock tests will indeed breaks once in a while. EasyMock forces you to do a complete recording of what you expect. This requires some discipline. You should really record what is expected not what the tested method currently needs. For instance, if it doesn't matter how many time a method is called on a mock, don't be afraid of using andStubReturn. Also, if you don't care about a parameter, use anyObject() and so on. Thinking in TDD can help on that.
我的分析是，EasyMock测试会更频繁地中断，但是Mockito测试不会在您希望的时候中断.我希望考试能打破.至少我知道我的发展产生了什么影响.当然，这是我个人的观点.
My analyze is that EasyMock tests will break more often but Mockito ones won't when you would want them to. I prefer my tests to break. At least I'm aware of what was the impacts of my development. This is of course, my personal point of view.
这篇关于EasyMock与Mockito:设计与可维护性?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！