我们最终将单元测试代码库从JUnit 3迁移到JUnit4。我们还大量使用了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类定义的所有方法,这些方法仅回显嘲笑。也有@RunWith注释,以避免忘记将其添加到测试类的可能性。

最佳答案

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

10-06 07:11