Strructureを開いて、Ploblemsに何も表示されなければ、ライブラリが正常に導入されています。依存オブジェクトとその依存性を見つけるメイン画面のMyFragmentのソースコードを見ると、依存オブジェクトは、mSharedPrefsで、SharedPreferencesに依存しています。SharedPrefsModuleをを作ります。provideSharedPrefsに、@Provideアノーテーションを付けます。メソッド名は、プレフィックスに、provideを付けるのが慣例になっています。provideSharedPrefsは、仮実装で、nullを返すように記述していますが、後で修正します。アノーテーションはプロダクションコードと同様に付けます。MyFragment.CONFIG_MAME;を記述しています。テスト時には、本番環境のプリファレンスに影響しないように、プリファレンスファイルはプレフィックス”test_”を付けたものを使用するようにします。これは、後で使用します。mSharedPrefs;のように、@Injectアノーテーションを付けます。@Componentアノーテーションを用いてinterfaceを作り、第2ステップで作られた@Moduleアノーテーションを持つクラスを加えるテストで、依存性注入によって、プリファレンスファイルを、テスト用プリファレンスファイルに置き換えるために、本記事では、componetのクラスを、debug/javaディレクトリに作ります。パッケージに作ります。}}ここで、依存オブジェクトmockSharedPrefsに@Injectアノーテーションを付けています。setUp、tearDownでは、依存性注入の設定のオン、オフを行う設定を後で行います。SharedPrefsComponentを作ります。}}iterfaceには、@Componentアノーテーションを付け、modilesで、モジュールクラスを列挙します。複数ある場合は、{}の中に、,区切りでクラスを記述します。依存性を注入するクラスに対して、injectメソッドを定義します。test);と定義しています。Initializerを定義し、SharedPrefsComponentを返す、initメソッドを定義します。メソッドの中身は後で本実装するので、今は、仮実装で、nullを返すようにしています。Appを作るMyFragmentとInjectedBaseActivityTestの両方から依存性注入を行えるように、次の内容のApplicationを継承したAppクラスを作ります。}}そして、Manifestファイルに、このAppを登録します。これを忘れると、アプリが落ちるし、テストもできません。SharedPrefsComponent.Initializer.init(false);の行が実行され、本番環境では、debugモードがfalseになります。interfaceのオブジェクトを作るこの時点で、プロジェクトをビルドして、todoコメントをした所を本実装していきます。Daggerと打つと、DaggerSharedPrefsComponentと補完され、builder()、debugSharedPrefsModule()メソッドを順に呼ぶことができるようになります。DebugSharedPrefsModule(mockMode)を記述します。最後に、build()メソッドを呼ぶと、ビルドエラーの印が消えます。StudioかIntelliJの下のバーにあるTODOをクリックして、todoコメントがある所を見つけ、修正していきます。}のように修正します。mockModeがtrueの時は、テスト用SharedPreferencesを返すようにし、falseの時は、プロダクション用のSharedPreferencesを返すようにします。本記事では、mockModeがtrueの時、provideSharedPrefsメソッドが、テスト用プリファレンスファイルを使用したSharedPreferencesを返すようにしていますが、コメントにあるように、Mockitoのmockを使用することもできます。その場合、プリファレンスの読み込み、表示のテストはできますが、プリファレンスファイルへの書き込み、更新のテストはできません。}のように修正します。テスト用クラスでは、setUpメソッド内で、Appオブジェクトを取得して、setMockModeでモックモードにして、app.component()でコンポネントを呼んで、injectで依存性注入を行います。テストケースごとに、プリファレンスの内容を消すようにしています。tearDownメソッド内で、モックモードをオフにしています。}プロダクション用には、実際のプリファレンスファイルを使うので、App.getInatnce()からApplicationインスタンスを得、getSharedPreferencesメソッドで、プロダクション用プリファレンスファイルを使用するプリファレンスを返します。}のように依存性注入を行います。これはしなくても、アプリもテストも動きます。更新がテストできない。}}ここで、わかりにくいですが、テストクラスに出てくるgetSharedPrefs()に関してですが、テストクラスがInjectedBaseActivityTestを継承していて、InjectedBaseActivityTestに、モックのmockSharedPrefsを返すgetSharedPrefsメソッドが定義されているので、テストクラスのgetSharedPrefs()はモックのプリファレンスを返します。従って、テストでは、テスト用のプリファレンスファイルを使用してテストを行っています。ここでは、依存性注入を行って、プリファレンスファイルをテスト用に置き換えていますので、プリファレンスへの書き込み、読み込みができます。テストは次の項目をテストしています。本記事で扱ったサンプルプロジェクトを公開します。2で依存性注入を行いテストするサンプルも公開します。はじめに以前公開したORMLiteを使ったアドレス帳アプリandropenguin/AddressBookORMliteをテストしやすいように書き直し、Espressoでテストを行います。住友孝郎@cattaka_net氏のスライド開発を効率的に進めるられるまでの道程を読んで、データベース、Adapterがあるアプリで、どうテストしやすく書き換えるか、どうテストするか学びました。上記スライドによると、データベース、Adapter、プリファレンスの単体テストを行い、また、Activityのテスト、つまりUIのテストは、データベース、Adapter、プリファレンスをダミーに置き換えてテストを行うと、いいそうです。上記スライドは、テストのやり方の概要を紹介するもので、実際のテストの仕方は、cattaka/FastCheckListのサンプルを読んで学びました。以前公開したアドレス帳アプリAddressBookORMliteをテストしやすいように、adapter、app、asynctask、core、db、entityのサブパッケージを作ります。以前のアプリでは、adapterやdbに関するコードは、アクティビティに書いていましたし、また、DBから全件取得するコードを書いていたにも関わらず、AsyncTaskLoaderを使用していなかったので、asynctaskのサブパッケージも導入しました。あと、coreサブパッケージにあるクラスは、住友孝郎@cattaka_net氏が導入しているものです。プロダクションコードプロダクションコードの各クラスを見ていきます。entityサブパッケージPersonクラスとAddressクラスは以下の通りです。内容は以前と変わっていないと思います。dbサブパッケージデータベースに関するコードは次の通りです。以前は、CRUDのコードを他のクラスに書いていましたが、テストしやすいように、OpenHelperクラスに書きました。coreサブパッケージ住友孝郎@cattaka_net氏のコードを使用しています。起動方法で入手した、absractなAsyncTaskLoaderを使用します。下記コードで、使用ケースに応じて、Tにクラス名を書いて使用します。}}実際に使用するPersonLoader.javaは以下の通りです。上記AbstractAsyncTaskLoaderクラスで、TをListにしたクラスを継承します。AsyncTaskLoaderクラスについては、十分テストが行われていると思われるので、loadInBackground内の処理のみをテストするため、loadInBackground内の処理をメソッド抽出しています。appサブパッケージアクティビティを置いたサブパッケージです。DBをproduction用、test用に切り替えられるようにする。DBをproduction用、test用に切り替えられるようにする。DBをproduction用、test用に切り替えられるようにする。ファイルを使用できるようになります。ContexLogic、ContexLogicFactoryクラスクラスについては、cattaka/FastCheckListのサンプルにファイルがあります。adapterサブパッケージアダプタのコードは、以前はMainActivity.javaに書いていましたが、テストしやすいように、独立なクラスにします。データベース、アダプター、プリファレンス、UIのテストをすべて行えます。app/build.gradleを以下のように編集します。applicationIdやtestApplicationIdは適宜修正します。不要なライブラリを参照しているかもしれません。app.testサブパッケージ住友孝郎@cattaka_net氏のBaseTestCase、TestContextLogic、TestUtil、UnlockKeyguardActivityクラスを使用します。ファイルは入手可能です。本記事では、データベースのクリア、ダミーデータの作成のために、BaseTestCaseを改変しました。persons)のようにList<Person>型の引数を持ちますので、そこにダミーのデータを入れて、Viewが期待した通りになるかテストします。AsyncTaskLoaderのテストPersonLoaderのテストは、メソッド抽出したgetPersonsメソッドが、ダミーなデータ入力に対して、期待した値を返すかでテストします。);で置き換えることが重要です。これを行うと、データベースファイルは、実際のデータベースファイル名の頭に”test_”がついて、ダミーのデータベースファイルでテストを行うことができます。coreサブパッケージのクラスのテストFastCheckList/app/src/androidTest/java/net/cattaka/android/fastchecklist/core/で、パッケージを修正して、テストします。データベースのテストデータベースのテストはダミーのデータファイルを使用してテストを行います。);で置き換えることが重要です。これを行うと、データベースファイルは、実際のデータベースファイル名の頭に”test_”がついて、ダミーのデータベースファイルでテストを行うことができます。UIのテストアクティビティ、つまりUIのテストは、ダミーなデータベースファイルを使用してテストを行います。