EasyMock 与 Mockito：设计与可维护性？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题吗？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

7 年前已关闭。

Answer 1

我是一名 EasyMock 开发人员，所以有点偏颇，但当然我在大型项目中使用过 EasyMock。

我的观点是 EasyMock 测试确实偶尔会中断。 EasyMock 强制您完整记录您所期望的内容。这需要一些纪律。您应该真正记录预期的内容，而不是测试方法当前需要的内容。例如，如果在模拟上调用某个方法多少次并不重要，请不要害怕使用 andStubReturn。另外，如果您不关心参数，请使用 anyObject() 等。 TDD 思维可以对此有所帮助。

我的分析是，EasyMock 测试会更频繁地中断，但 Mockito 测试不会在您想要的时候中断。我更希望我的测试被打破。至少我知道我的发展带来了哪些影响。这当然是我个人的观点。

Answer 2

我认为你不应该太担心这个。 Easymock 和 Mockito 都可以配置为“严格”或“良好”，唯一的区别是默认情况下 Easymock 是严格的，而 Mockito 是良好的。

与所有测试一样，没有硬性规定，您需要平衡测试置信度和可维护性。我通常发现某些功能或技术领域需要高度的信心，对此我会使用“严格”模拟。例如，我们可能不希望 debitAccount() 方法被多次调用！然而，在其他情况下，模拟实际上只不过是一个存根，因此我们可以测试代码的真正“内容”。

在 Mockito 诞生的早期，API 兼容性是一个问题，但现在有更多工具支持该框架。 Powermock（个人最喜欢的）现在有一个mockito扩展

Answer 3

说实话我更喜欢mockito。一直将 EasyMock 与 unitils 结合使用，两者的组合通常会导致异常，例如 IllegalArgumentException: not an interface 以及 MissingBehaviorExceptions。在这两种情况下，代码和测试代码都很好。看来 MissingBehaviorException 是由于使用 createMock （使用类扩展！！）创建的模拟对象确实产生了此错误。当使用@Mock时它确实有效！我不喜欢这种误导行为，对我来说，这清楚地表明它的开发人员不知道他们在做什么。一个好的框架应该总是易于使用且不含糊。 IllegalArgumentException 也是由于 EasyMock 内部的一些混合造成的。而且，录音也不是我想做的。我想测试我的代码是否抛出异常以及它是否返回预期结果。与代码覆盖率相结合对我来说是正确的工具。每当我将一行代码放在前一行代码之上或之下时，我不希望我的测试中断，因为这会提高性能等。使用mockito就没有问题了。使用 EasyMock，即使代码没有损坏，也会导致测试失败。那很糟糕。这需要时间，因此需要金钱。您想要测试预期的行为。你真的关心事情的顺序吗？我想在极少数情况下你可能会这样做。那就用Easymock吧。在其他情况下，我认为您使用mockito 编写测试的时间会少得多。

亲切的问候
劳伦斯

Answer 4

我不会争论这些框架的测试可读性、大小或测试技术，我相信它们是相同的，但通过一个简单的示例，我将向您展示差异。

假设：我们有一个类负责在某处存储某些内容：

public class Service {

    public static final String PATH = "path";
    public static final String NAME = "name";
    public static final String CONTENT = "content";
    private FileDao dao;

    public void doSomething() {
        dao.store(PATH, NAME, IOUtils.toInputStream(CONTENT));
    }

    public void setDao(FileDao dao) {
        this.dao = dao;
    }
}

我们想测试它：

Mockito：

public class ServiceMockitoTest {

    private Service service;

    @Mock
    private FileDao dao;

    @Before
    public void setUp() {
        MockitoAnnotations.initMocks(this);
        service = new Service();
        service.setDao(dao);
    }

    @Test
    public void testDoSomething() throws Exception {
        // given
        // when
        service.doSomething();
        // then
        ArgumentCaptor<InputStream> captor = ArgumentCaptor.forClass(InputStream.class);
        Mockito.verify(dao, times(1)).store(eq(Service.PATH), eq(Service.NAME), captor.capture());
        assertThat(Service.CONTENT, is(IOUtils.toString(captor.getValue())));
    }
}

EasyMock：

public class ServiceEasyMockTest {
    private Service service;
    private FileDao dao;

    @Before
    public void setUp() {
        dao = EasyMock.createNiceMock(FileDao.class);
        service = new Service();
        service.setDao(dao);
    }

    @Test
    public void testDoSomething() throws Exception {
        // given
        Capture<InputStream> captured = new Capture<InputStream>();
        dao.store(eq(Service.PATH), eq(Service.NAME), capture(captured));
        replay(dao);
        // when
        service.doSomething();
        // then
        assertThat(Service.CONTENT, is(IOUtils.toString(captured.getValue())));
        verify(dao);
    }
}

如您所见，两个测试都相当相同，并且都通过了。
现在，让我们假设其他人更改了服务实现并尝试运行测试。

新服务实现：

dao.store(PATH + separator, NAME, IOUtils.toInputStream(CONTENT));

在 PATH 常量末尾添加分隔

符 现在测试结果如何？首先，两个测试都会失败，但会出现不同的错误消息：

EasyMock：

java.lang.AssertionError: Nothing captured yet
    at org.easymock.Capture.getValue(Capture.java:78)
    at ServiceEasyMockTest.testDoSomething(ServiceEasyMockTest.java:36)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

Mockito：

Argument(s) are different! Wanted:
dao.store(
    "path",
    "name",
    <Capturing argument>
);
-> at ServiceMockitoTest.testDoSomething(ServiceMockitoTest.java:34)
Actual invocation has different arguments:
dao.store(
    "path\",
    "name",
    java.io.ByteArrayInputStream@1c99159
);
-> at Service.doSomething(Service.java:13)

EasyMock 测试中发生了什么，为什么没有捕获结果？是不是store方法没有执行，但是等一下，是的，为什么EasyMock要骗我们呢？

这是因为 EasyMock 在一行中混合了两种职责 - 存根和验证。这就是为什么当出现问题时很难理解哪个部分导致了故障。

当然你可以告诉我 - 只需更改测试并在断言之前移动验证即可。哇，你是认真的吗，开发人员应该记住一些由模拟框架强制执行的神奇命令吗？

顺便说一句，它不会有帮助：

java.lang.AssertionError: 
  Expectation failure on verify:
    store("path", "name", capture(Nothing captured yet)): expected: 1, actual: 0
    at org.easymock.internal.MocksControl.verify(MocksControl.java:111)
    at org.easymock.classextension.EasyMock.verify(EasyMock.java:211)

仍然，它告诉我该方法没有执行，但它是，只是带有另一个参数。

为什么 Mockito 更好？该框架不会在一个地方混合两种职责，当您的测试失败时，您将很容易理解原因。

Answer 5

如果我们关心代码的设计，那么 Easymock 是更好的选择，因为它通过期望的概念向您提供反馈

有趣的反馈。我发现“期望概念”让许多开发人员投入更多精力和精力。在测试中更多的期望只是为了满足 UnexpectedMethodCall 问题。它如何影响设计？

当您更改代码时，测试不应中断。当功能停止工作时，测试应该中断。如果有人希望测试在发生任何代码更改时中断，我建议编写一个测试来断言 java 文件的 md5 校验和:)