2

Mockito を使用してビジネス オブジェクトの単体テストを行っています。ビジネス オブジェクトは、通常は DB からデータを取得する DAO を使用します。ビジネス オブジェクトをテストするには、別のメモリ内 DAO (データを HashMap に保持する) を使用する方が、すべてのオブジェクトを記述するよりも簡単であることに気付きました。

when(...).thenReturn(...)

ステートメント。このような DAO を作成するために、次のように DAO インターフェースを部分的にモックすることから始めました。

when(daoMock.getById(anyInt())).then(new Answer() {
    @Override
    public Object answer(InvocationOnMock invocation) throws Throwable {
        int id = (Integer) invocation.getArguments()[0];
        return map.get(id);
    }
});

しかし、Mockito を使用せずに（インメモリ HashMap を使用して）まったく新しい DAO 実装を自分で実装し（その InvocationOnMock オブジェクトから引数を取得する必要はありません）、テストされたビジネス オブジェクトにこの新しいダオ。

さらに、部分的なモックは悪い習慣と見なされていることを読みました。私の質問は次のとおりです。私の場合、私が行っていることは悪い習慣ですか? 欠点は何ですか？私にはこれで問題ないように思えますが、潜在的な問題が何であるか疑問に思っています。

4

2 に答える 2

1

クラスをテストするときは、Mockito 製のモックと偽物を組み合わせて使用​​することがよくあります。あなたの状況では、偽の実装の方が良いように聞こえることに同意します。

部分モックに特に問題はありませんが、実際のオブジェクトを呼び出しているときと、モックされたメソッドを呼び出しているときを判断するのが少し難しくなります。元のクラスに無害に見える変更を加えると、部分モックの実装が変更され、テストが機能しなくなる可能性があります。

柔軟性がある場合は、呼び出す必要があるメソッドを公開するインターフェイスを抽出することをお勧めします。これにより、モックとフェイクのどちらを選択するかが簡単になります。

偽物を作成するには、単純なクラスを使用して Mockito を使用せずにその小さなインターフェイスを実装します (必要に応じて、テストにネストします)。これにより、何が起こっているかを非常に簡単に確認できます。欠点は、非常に複雑な Fake を作成すると、Fake もテストする必要があることに気付く場合があることです。優れた Fake 実装を利用できる多くのテストがある場合、これは追加のコードに値する可能性があります。

「モックはスタブではない」というマーティン・ファウラー (彼の著書「リファクタリング」で有名) の記事を強くお勧めします。彼は、さまざまな種類のテスト ダブルの名前と、それらの違いについて説明します。

于 2012-10-03T16:52:38.873 に答える