6

理由はわかりませんが、私はいつも JMock テストを次のように書いてきました。

@Test
public void testMyThing() throws Exception {
    mockery.checking(new Expectations() {{
        oneOf(mockObj).foo();
    }});
    testObj.bar(); // calls mockObj.foo()
    mockery.assertIsSatisfied();
}

しかし、多くのテストがある場合は、分解に移行assertIsSatisfiedした方がよいでしょうか?

@After
public void tearDown() throws Exception {
    mockery.assertIsSatisfied();
}
4

2 に答える 2

5

これを行うための推奨される方法は、JMock ランナーを使用することです。クラスに注釈を付ける

@RunWith(JMock.class)
public class TestClass {

これにより、テスト ライフサイクルの適切な場所でアサーションが呼び出されます。失敗が正しく報告されず、他のクリーンアップが台無しになる可能性があるため、ティアダウンは適切な場所ではありません。

リポジトリには、新しい @Rule インフラストラクチャで動作する嘲笑ルールもあります。

于 2011-08-23T22:47:12.573 に答える
0

Yes, I tend to do it in teardown. It keeps the focus of the individual test methods on what they're actually testing, by removing the boilerplate out into the @After- it's critical to me that tests are as expressive and readable as possible.

In fact, I sometimes take it further than that, and use a JMockSupport base class that handles the Mockery for me (as well as providing convenience implementations of mock(...)). This is just a convenience, of course, and by no means a requirement like it was in JUnit 3.

于 2011-07-08T12:58:46.733 に答える