1

ユニットテストのコードベースをついに JUnit 3 から JUnit 4 に移行しました。JMock 2 も多用しています。

JUnit 3 では、JMock はテスト用の便利な基本クラス (MockObjectTestCase) を提供します。これは、それ自体が Junit の TestCase のサブクラスであるだけでなく、モック フレームワークに関するさまざまなハウスキーピング タスクを処理します。これにより、テスト クラスの作業がかなり楽になります。

現在、JUnit4 では、JMock はそのようなサポートを提供していません。テスト クラスは、Mockery オブジェクトを手動で作成する必要があり、正しいテスト ランナー アノテーションを使用することを覚えておく必要があり、すべてのモック関連の操作をモックに委譲する必要があります。つまり、JUnit 3 テストで必要とされていたよりもはるかに多くの責任がテスト クラスに課せられます。

JUnit4 の魅力の 1 つは何かをサブクラス化する必要がないことですが、この 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 アノテーションもあります。

4

3 に答える 3

2

私もこの移行を行いましたが、それは苦痛です。彼らが基本クラスのメカニズムをビニングした理由を理解できます.Spring JUnit対応の基本クラスでJMock基本クラスをジャグリングしようとしましたが、それは明らかにうまくいきません.

この移行に着手すると、「最適化」のために見つけた領域の 1 つは、テストごとに新しい Expectation オブジェクト (およびインスタンス) を作成するのではなく、モック オブジェクトの一般的な操作をカプセル化する適切な Expectation ベース クラスを作成することでした。そうすれば少しは悲しみが和らぐでしょう。

于 2009-07-14T10:43:05.347 に答える
1

基本クラスを持つことにも問題があります。以前のバージョンでは、異なるテストフレームワークの基本クラスを組み合わせようとして苦労しました。だから私たちは継承よりも作曲に行きました。新しい@Rule構造で何ができるかを見るのは興味深いでしょう。

于 2009-09-05T11:44:54.353 に答える
1

いいえ、そのようなサポートはありません。

JMock 1 のテスト基本クラスは多くの問題を引き起こしました。1 つのクラスしか拡張できず、基本クラスも定義されている他のテスト フレームワークで JMock を使用できなかったからです。そのため、JMock2 では継承ではなく委譲を採用しました。

とはいえ、クラスに @RunWith(JMock.class) のアノテーションを付ければ、JMock2 の JUnit3 サポート ライブラリの MockObjectTestCase クラスを使用できる可能性があります。しかし、私は試していません。

自動リフレクションによってコンテキストとモックオブジェクトを作成する「自動モッキング」JUnit4 ランナーのリクエストがありました。これが好きな人もいれば、本当に嫌いな人もいます。この機能が必要な場合は、JMock JIRA で課題に投票してください。

于 2009-07-14T10:40:23.560 に答える