Serviceのユニットテスト

Testing | Android Developers
Testing Overview | Android Developers
Service Testing | Android Developers
Serviceのユニットテストにはandroid.test.ServiceTestCaseというクラスが用意されている。
ServiceTestCase | Android Developers

自分用にドキュメントの一部を拙訳する。間違ってるかもしれないので閲覧注意です。

ライフサイクルのサポート。サービスは指定された順序の呼び出しでアクセスされる(Application Fundamentals | Android Developersを参照)。Serviceのライフサイクルをサポートするために、ServiceTestCaseは下記を実行する。

  • setUp()メソッドは各テストメソッドの前に呼び出される。基底の実装はsystem contextを取得する。もしsetUp()をオーバーライドする場合はsuper.setUp()をステートメントの最初に呼び出すこと。
  • テストケースはテストメソッドがstartService(Intent)かbindService(Intent)を呼ぶまでonCreate()の呼び出しを待つ。これにより、開発者はServiceを実行する前に、テストロジックや追加したフレームワークのセットアップや調整の機会を得られる。
  • テストメソッドからServiceTestCase.startService()かServiceTestCase.bindService()を呼び出したときテストケースはまずService.onCreate()を呼び出して、さらにService.startService()またはService.bindService()のどちらか適切なほうを呼び出す。追跡に必要な値をストアしたりもする。
  • それぞれのテストメソッドが終わったあと、テストケースはtearDown()を呼び出す。このメソッドは適切な呼び出しによってサービスの停止と破棄を行い、どうサービスを開始したかに依存している。もしtearDown()をオーバーライドした場合はステートメントの最後にsuper.tearDown()を呼び出す必要がある。

依存性の注入(DI)。Serviceは特性としてContextとApplicationの2つに依存している。ServiceTestCaseフレームワークを使うと、依存する部分を修正したりモックに差し替えたりできる。それによって、環境に依存しないユニットテストを実行可能にする。

デフォルトでは、テストケースは完全なsystem contextとgenericなMockApplicationオブジェクトを注入される。開発者は、setContext()やsetApplication()のいずれかの呼び出しで、差し替えが可能。これはstartService()かbindService()の前に行わなければならない。テスティングフレームワークはContextの代わりを備えている。MockContext, RenamingDelegatingContext, ContextWrapper, IsolatedContextなど。