1. 概要

このチュートリアルでは、 MockitoAPIの標準の静的mockメソッドのさまざまな使用法を説明します。

Mockitoフレームワークに焦点を当てた他の記事(MockitoVerifyMockitoWhen/ Then など)と同様に、以下に示すMyListクラスがテストケースで嘲笑される:

public class MyList extends AbstractList<String> {
    @Override
    public String get(int index) {
        return null;
    }

    @Override
    public int size() {
        return 1;
    }
}

2. シンプルなモッキング

mock メソッドの最も単純なオーバーロードされたバリアントは、モックされるクラスの単一のパラメーターを持つものです。

public static <T> T mock(Class<T> classToMock)

このメソッドを使用して、クラスをモックし、期待値を設定します。

MyList listMock = mock(MyList.class);
when(listMock.add(anyString())).thenReturn(false);

次に、モックでメソッドを実行します。

boolean added = listMock.add(randomAlphabetic(6));

次のコードは、モックでaddメソッドを呼び出したことを確認します。 呼び出しは、前に設定した期待値と一致する値を返します。

verify(listMock).add(anyString());
assertThat(added, is(false));

3. モックの名前でモックする

このセクションでは、 mock メソッドの別の変形について説明します。これには、モックの名前を指定する引数が含まれています。

public static <T> T mock(Class<T> classToMock, String name)

一般的に言って、モックの名前は動作するコードとは何の関係もありません。 ただし、モックの名前を使用して検証エラーを追跡するため、デバッグに関しては役立つ場合があります。

失敗した検証からスローされた例外メッセージにモックの提供された名前が含まれていることを確認するために、 TestRule インターフェイスのJUnit実装、 ExpectedException に依存し、それをテストクラス:

@Rule
public ExpectedException thrown = ExpectedException.none();

このルールを使用して、テストメソッドからスローされた例外を処理します。

次のコードでは、 MyList クラスのモックを作成し、myMockという名前を付けます。

MyList listMock = mock(MyList.class, "myMock");

次に、モックのメソッドに期待値を設定して実行します。

when(listMock.add(anyString())).thenReturn(false);
listMock.add(randomAlphabetic(6));

意図的に失敗した検証を作成し、モックに関する情報を含むメッセージで例外をスローする必要があります。 そのためには、まず例外に期待を設定する必要があります。

thrown.expect(TooLittleActualInvocations.class);
thrown.expectMessage(containsString("myMock.add"));

次の検証が失敗し、例外がスローされることが予想されます。

verify(listMock, times(2)).add(anyString());

スローされた例外のメッセージは次のとおりです。

org.mockito.exceptions.verification.TooLittleActualInvocations:
myMock.add(<any>);
Wanted 2 times:
at com.baeldung.mockito.MockitoMockTest
  .whenUsingMockWithName_thenCorrect(MockitoMockTest.java:...)
but was 1 time:
at com.baeldung.mockito.MockitoMockTest
  .whenUsingMockWithName_thenCorrect(MockitoMockTest.java:...)

ご覧のとおり、例外メッセージにはモックの名前が含まれています。これは、検証が失敗した場合に障害点を見つけるのに役立ちます。

4. Answerでモックする

ここでは、 mock バリアントの使用方法を示します。このバリアントでは、作成時のインタラクションに対するモックの回答の戦略を構成します。 Mockitoドキュメントのこのmockメソッドのシグネチャは、次のようになります。

public static <T> T mock(Class<T> classToMock, Answer defaultAnswer)

Answerインターフェースの実装の定義から始めましょう。

class CustomAnswer implements Answer<Boolean> {
    @Override
    public Boolean answer(InvocationOnMock invocation) throws Throwable {
        return false;
    }
}

上記のCustomAnswerクラスを使用して、モックを生成します。

MyList listMock = mock(MyList.class, new CustomAnswer());

メソッドに期待値を設定しない場合、CustomAnswerタイプで構成されたデフォルトの回答が機能します。 これを証明するために、期待値の設定手順をスキップして、メソッドの実行にジャンプします。

boolean added = listMock.add(randomAlphabetic(6));

次の検証とアサーションは、Answer引数を指定したmockメソッドが期待どおりに機能したことを確認します。

verify(listMock).add(anyString());
assertThat(added, is(false));

5. MockSettingsでモックする

この記事で取り上げる最後のmockメソッドは、MockSettingsタイプのパラメーターを持つバリアントです。 このオーバーロードされたメソッドを使用して、非標準のモックを提供します。

MockSettings インターフェイスのメソッドでサポートされるカスタム設定がいくつかあります。たとえば、 invocationListeners を使用して現在のモックでメソッド呼び出しのリスナーを登録したり、serializableを使用してシリアル化を構成したりします。 、 spiedInstance でスパイするインスタンスを指定し、useConstructorでモックをインスタンス化するときにコンストラクターを使用しようとするようにMockitoを構成します。

便宜上、前のセクションで紹介した CustomAnswer クラスを再利用して、デフォルトの回答を定義するMockSettings実装を作成します。

MockSettings オブジェクトは、ファクトリメソッドによってインスタンス化されます。

MockSettings customSettings = withSettings().defaultAnswer(new CustomAnswer());

新しいモックの作成では、その設定オブジェクトを使用します。

MyList listMock = mock(MyList.class, customSettings);

前のセクションと同様に、MyListインスタンスのaddメソッドを呼び出し、MockSettingsを使用してmockメソッドを確認します。 ]引数は期待どおりに機能します:

boolean added = listMock.add(randomAlphabetic(6));
verify(listMock).add(anyString());
assertThat(added, is(false));

6. 結論

この記事では、Mockitoのmockメソッドについて詳しく説明しました。 これらの例とコードスニペットの実装は、GitHubプロジェクトにあります。