mockitoマニュアル

以下はMockitoクラスJavaDocの訳（Version 1.8.1、現在翻訳進行中)

以下の例はListをモックしているが、これは誰もがそのインターフェース（add, get, clear等のメソッド）を知っているからだ。たぶん、実際にはListをモックすることなんかないだろうけど。

ふるまいを検証してみよう

 //Mockitoをstatic importすると、コードがきれいに書けるよ
 import static org.mockito.Mockito.*;
 
 //モックを作る
 List mockedList = mock(List.class);

 //モックオブジェクトを使ってみる
 mockedList.add("one");
 mockedList.clear();

 //検証する
 verify(mockedList).add("one");
 verify(mockedList).clear();

モックはすべての作用を記録している。後で興味のある作用についてだけ検証することができる。

スタブを作ってみよう

 //コンクリートクラスのモックを作成することができる、インターフェースだけじゃなく
 LinkedList mockedList = mock(LinkedList.class);
 
 //スタブ化
 when(mockedList.get(0)).thenReturn("first");
 when(mockedList.get(1)).thenThrow(new RuntimeException());
 
 //以下は"first"を表示する
 System.out.println(mockedList.get(0));
 
 //以下は実行時例外を投げる
 System.out.println(mockedList.get(1));
 
 //以下は"null"を表示する、get(999)はスタブされていないから。
 System.out.println(mockedList.get(999));

　//スタブを検証することもできるけれども、冗長だろう。
 //If your code cares what get(0) returns then something else breaks (often before even verify() gets executed).
 //If your code doesn't care what get(0) returns then it should not be stubbed. Not convinced? See here.
 verify(mockedList).get(0);

デフォルトでは、すべての返り値のあるメソッドについては、モックはnull, 空のコレクション、適当なプリミティブやプリミティブラッパ値（例えば、0, false, ...）などを返す。
スタブ化はオーバライドできる。例えば、共通のスタブ化をfixtureセットアップで行い、テストメソッド中でオーバライドする。ただ、スタブ化のオーバライドは「スタブしすぎ」の匂いも漂う。
一度スタブ化されると、何度呼び出されようが、同じ値を返す。
同じメソッドを同じ引数でスタブ化した場合、最後のスタブ化だけが生き残る。

引数の一致

Mockitoは引数が一致するかどうかを通常のJavaスタイルでチェックする。つまり、equals()メソッドを使う。しかし、もっとフレキシブルな方法が必要になることもある。その場合はmatcher引数を使うことができる。

 //(Mockitoに）付属のanyInt()matcherを使ってスタブ化
 when(mockedList.get(anyInt())).thenReturn("element");
 
 //hamcrestを使ってスタブ化。ここではisValid()メソッドが、あなたの作成したhamcrest-matcherを返すものとする。
 when(mockedList.contains(argThat(isValid()))).thenReturn("element");
 
 //以下は"element"を表示する
 System.out.println(mockedList.get(999));
 
 //引数matcherを使って検証することもできる。
 verify(mockedList).get(anyInt());

引数matcherによってフレキシブルな検証とスタブ化をすることができる。ここにビルトインmatcher、カスタム引数matcher、hamcrest-matcherの情報がある。

カスタム引数matcherについてはArgumentMatcherを参照のこと。

複雑な引数マッチングについて妥当性を保つこと。 The natural matching style using equals() with occasional anyX() matchers tend to give clean & simple tests. equals()によるマッチングを許すように、あるいはequals()を実装するようにコードをリファクタリングした方が良い場合もある。

また、セクション１５あるいはArgumentCaptorを読むこと。ArgumentCaptorは後のアサーションのために、引数値をキャプチャする特別な引数matcherである。

引数matcherに関する注意:

引数matcherを使う場合は、すべての引数がmatcherで提供されなければならない。

例: (この例は検証のみだが、スタブ化でも同様):

   verify(mock).someMethod(anyInt(), anyString(), eq("third argument"));
   //上は正しい。eq()も引数matcherである
   
   verify(mock).someMethod(anyInt(), anyString(), "third argument");
   //上は不正。なぜなら、三番目の引数は引数matcherとして提供されていない。

mockito/Manual

mockitoマニュアル

ふるまいを検証してみよう

スタブを作ってみよう

引数の一致