「Androidアプリ テスト技法」第３章その３
- 作者: 生路茂太,井芹洋輝,神原健一,長谷川孝二,松木晋祐,宮田友美,吉澤毅
- 出版社/メーカー: 秀和システム
- 発売日: 2013/02
- メディア: 単行本
- この商品を含むブログ (2件) を見る
バックグラウンド
非同期で動作するServiceとAsyncLoaderのテスト方法
ServiceTestCase
Serviceをテストするためのテストケース。 startServiceやbindService, shutdownServiceといったメソッドを持っている。
LoaderTestCase
Honycomb(API 11)で導入されたLoaderをテストするためのテストケースクラス。LoaderTestCase#getLoaderResultSynchronously()は、本来非同期実行されるLoaderの処理を同期実行して結果を返してくれる。
外部要因の影響を受けるときのテスト方法
SQLite
SQLiteでのデータアクセスのテストを行うときは、setUpでデータベースを初期化し、テストに必要なデータを登録できるようにしておく。
Fixture
テストを実行し、成功させるために、データを準備したりすることをFixtureと呼ぶ
RenamingDelegatingContext
第二引数の文字列を対象プロジェクトで使用するデータベース名やファイル名の前に付加して、 テスト専用データベースやファイルを作成するためのContext。 SQLiteOpenHelperを作成するときのContextにはこれを使うとよい。
mockitoによる依存オブジェクトの置き換え
外部のデータや実行するたびに値が変化するような DOC(Depended-on Component)は、常に一定の値を返すオブジェクトに置き換えると対象のテストが容易になる。
ただし、依存オブジェクトの置き換えは、容易な場合と困難な場合があるため、 あらかじめ置き換えやすいように対象アプリを設計しておく必要がある。
-
依存オブジェクトの置き換えるのに便利なフレームワーク。jarファイルをクラスパスに追加する
-
mokitoが生成するMockオブジェクトをdexに変換するためのライブラリ。公開されている２つのjarをlibsの下に配置するだけ
間接入力
when()で指定されたメソッドの呼び出しの結果を、thenReturn()で指定した値に置き換えるテストスタブ を定義できる
間接出力
依存オブジェクトに対して値を設定する部分の検証が可能。厳密にテストしようとすると、テスト対象のロジックをトレースするようなテストコードになりやすい(ロジックに依存しやすい)ため、テストの容易性を向上させることを検討したほうがよいらしい
InOrderによる間接出力の厳密な検証
InOrder()を使うと、メソッド呼び出し順の検証も可能
Spyによる依存オブジェクト本来の振る舞いの再現
Mockito.mock()で作ったモックオブジェクトは、when()で定義されていないメソッドについてはnullを返す。 特定のメソッドを除いて本来の振る舞いをして欲しい時や、全てのメソッドが本来の振る舞いをした上で、verify()さえできればよい時には、Mockito.spy()で作ったオブジェクトを使うとよい。
モックオブジェクトの制限
言語仕様上、以下のケースではモックオブジェクトを生成できない
- finalクラス
- finalメソッド
- staticメソッド(クラスメソッド)
- equals() hashCode()のオーバーライド
HTTP通信のテスト
HTTP通信のユニットテスト
mockitoを使ってHttpClientオブジェクトをモックに置き換えて、高速で安定したユニットテストを行うようにする。
Webサービスからのレスポンスは、テストプロジェクトの/assetsに静的なファイルとして用意しておくと良い。
HTTP通信のユニットテスト(異常系)
HTTPステータスを返すメソッドを置き換えたり、 Mockito#thenThrow()で例外の発生を定義したりしてテストする。
HTTP通信のシステムテスト
開発者目線でのテストの他に、ユースケースやシナリオテストにおける異常系の項目を検出することで、以下 ような問題を検出できる可能性がある。
- 異常時の表示メッセージやリトライ処理は適切か
- UIへの操作(表示)をUIスレッド以外でしていないか
HTTP通信の接続先をテスト用のものに切り替える手段としては、以下のような手段がある。プロジェクトによって最適な方法を採用するとよい
- アプリ内のリソースを書き換えたテスト用ビルドを作る
- プロキシを利用してアクセス先を変更する
想定外の通信断のテスト
通信が不安定な環境を作り、ストレステストを実施するとよい
- ビルの地下等電波の届きにくい場所に端末を持ち込む
- 端末を電子レンジに入れる
- 端末をアルミホイルで包む
不安定な状態をテストするため、作業方法自体が不安定となる。テストにかけられるコストと相談して実施するとよい。
モックオブジェクトによる応答の固定化。そのためのモックオブジェクトの生成。 そして便利なフレームワークと、ユニットテストに対する見方がだいぶ変わって来ました。 今度からちゃんとテストを書けるような気がするw
さぁ、残り50ページ。この本の記事もあと２回くらいで終わりかな？
