Android Mockを利用してHTTP通信をテストするには：Androidアプリ開発テスト入門（5）（3/3 ページ）

» 2014年06月02日 13時00分公開

[長谷川孝二，日本Androidの会テスト部]

モックに対する操作を検証するには

　先のテストコードの最後に、以下のように書かれていました。

        // モックの検証（メソッドの戻り値で判断できているので冗長な確認）
        AndroidMock.verify(mockHttpClient);

　「verify()」は、モックにあらかじめ定義したメソッドがすべて呼ばれたことを検証し、定義と異なる使われ方をしていた場合に例外を発生してテストを失敗させます。

　コメントに「冗長な確認」と書いていますが、これは筆者が「あまりverify()に頼らないように」するための戒めです。テスト対象メソッドの実装にまで踏み込んだ検証を乱用すると変更に弱いテストコードになってしまうので、verify()による検証は補助手段に留めるべきでしょう。

　verify()の検証内容は、モックの生成時点で以下の3パターン存在します。

createMock()で生成したモック
expect()で指定したメソッドの呼び出し順はチェックされないが、expect()されていないメソッドを呼び出すと例外を発生し、テストを失敗させる
createNiceMock()で生成したモック
最も制限の緩いモック。expect()で指定したメソッドの呼び出し順はチェックされず、またexpect()していないメソッドを呼び出されても例外は発生ない（型に応じて「0」「false」「null」のいずれかが返る）
createStrictMock()で生成したモック
メソッドの呼び出し順まで厳密に検証されるモック。expect()順と異なる順序でメソッドを呼ばれた時点で例外を発生し、テストを失敗させる

　いずれもverify()では、expect()されたにもかかわらず呼び出されていないメソッドが残っていると例外を発生してテストを失敗させます。StrictMockの利用例をHTTP通信の正常系テストケースから抜粋して紹介します。

        // 上で定義したモックオブジェクトを返すHttpResponseモック
        // ステータスを確認してからEntityを取得していること（順序）を確認するため、StrictMock.
        HttpResponse mockResponse = AndroidMock.createStrictMock(HttpResponse.class);
        AndroidMock.expect(mockResponse.getStatusLine()).andReturn(mockStatusLine);
        AndroidMock.expect(mockResponse.getEntity()).andReturn(mockHttpEntity);
        AndroidMock.replay(mockResponse);

　このように定義していると、getStatusLine()を呼び出さずに（つまり、HTTPステータスを確認せずに）getEntity()で本文を取得しているコードを検出できます。

コラム　「Test Double Pattern」とは

記事中ではモックオブジェクトと表現していますが、モックの定義や分類には、さまざまな流儀があります。

著名なユニットテストの実装パターン集である『xUnit Test Patterns（および同名の書籍）』では、これを「Test Double」と総称したうえで、テスト対象への間接入力を操作する「Test Stub」、テスト対象からの間接出力を受け取り記録する「Test Spy」、また間接出力の検証までオブジェクト内で行う「Mock Object」などに分類しています。

興味を持たれた方は、ぜひ原書や読書会のログなどを読んでみてください。