【问题标题】:Lack of support base class in Junit4/Jmock2Junit 4/Mock 2 中缺乏支持基类
【发布时间】:2009-09-05 19:44:54
【问题描述】:

我们终于将单元测试代码库从 JUnit 3 迁移到 JUnit 4。我们还大量使用了 JMock 2。

在 JUnit 3 中,JMock 为您的测试提供了一个有用的基类 (MockObjectTestCase),它本身是 Junit 的 TestCase 的子类,它处理有关模拟框架的各种内务工作。它使测试类的生活变得非常轻松。

现在有了 JUnit4,JMock 不再提供这样的支持。您的测试类必须手动创建一个 Mockery 对象,它必须记住使用正确的测试运行器注释,并且必须将所有与模拟相关的操作委托给模拟。简而言之,与 JUnit 3 测试相比,它赋予了测试类更多的责任。

现在我很欣赏 JUnit4 的部分魅力在于无需对某些东西进行子类化,但这种 JMock 情况似乎是倒退了一步,使得从 3 移植到 4 的工作比应有的要多。

我错过了什么吗?实际上有没有一种很好的方法来编写我的 JUnit4/Jmock2 测试类,而无需手动将所有管道添加到每个类中?当然,我可以编写自己的支持基类,但这似乎是 JMock2 API 的明显遗漏,我不得不怀疑我是否错过了重点。


编辑:这是可选支持类的源代码:

@RunWith(JMock.class)
public class JMockSupport {

    protected final Mockery mockery = new Mockery();

    protected void checking(ExpectationBuilder expectations) {
        mockery.checking(expectations);
    }

    protected <T> T mock(Class<T> typeToMock) {
        return mockery.mock(typeToMock);
    }

    protected <T> T mock(Class<T> typeToMock, String name) {
        return mockery.mock(typeToMock, name);
    }

    protected Sequence sequence(String name) {
        return mockery.sequence(name);
    }

    protected void setDefaultResultForType(Class<?> type, Object result) {
        mockery.setDefaultResultForType(type, result);
    }

    protected void setImposteriser(Imposteriser imposteriser) {
        mockery.setImposteriser(imposteriser);
    }

    protected void setNamingScheme(MockObjectNamingScheme namingScheme) {
        mockery.setNamingScheme(namingScheme);
    }

    protected States states(String name) {
        return mockery.states(name);
    }
}

这包含了 JUnit3 MockObjectTestCase 类定义的所有方法,这些方法只是与 mockery 相呼应。 @RunWith 注释也在那里,以避免忘记将其添加到测试类的可能性。

【问题讨论】:

    标签: java junit jmock


    【解决方案1】:

    我也做过这个迁移,这很痛苦。我可以理解他们为什么将基类机制装箱 - 我试图将 JMock 基类与启用 Spring JUnit 的基类结合起来,而这显然行不通。

    一旦我开始迁移,我发现“优化”的一个领域是创建适当的 Expectation 基类,封装模拟对象上的常见操作,而不是为每个测试创建一个新的 Expectation 对象(和实例)。这将为您省去一点悲伤。

    【讨论】:

      【解决方案2】:

      拥有基类也存在问题。在以前的版本中,我试图组合来自不同测试框架的基类。这就是为什么我们使用组合而不是继承。看看我们可以用新的@Rule 结构做什么会很有趣。

      【讨论】:

      • 我同意组合更加灵活,但是继承带来了便利。能挑就不错了。
      • 作为记录,我在 JMock 存储库中实现了一个 @Rule 上下文
      【解决方案3】:

      没有。没有这样的支持。

      JMock 1 中的测试基类引起了很多问题,因为您只能扩展一个类,因此人们无法将 JMock 与其他也定义了基类的测试框架一起使用。这就是我们在 JMock2 中使用委托而不是继承的原因。

      也就是说,只要您使用@RunWith(JMock.class) 注释您的类,您就可以使用 JMock2 的 JUnit3 支持库中的 MockObjectTestCase 类。但我没试过。

      有一个“自动模拟”JUnit4 运行程序的请求,它将通过自动反射为您创建上下文和模拟对象。有些人喜欢这样,有些人真的不喜欢。如果你想要这个功能,vote for the issue in the JMock JIRA

      【讨论】:

      • 哦,你好 Nat,没想到会在这里找到你 :) 我已经修改了我的问题以包含建议的基类的来源。请注意,它完全是可选的,但确实让生活更轻松。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-04-02
      • 2011-06-03
      • 1970-01-01
      • 2018-03-10
      • 1970-01-01
      相关资源
      最近更新 更多