projectをsyncすると、次のようなエラーが発生する。gradle.propertiesを作成するといい。android.useDeprecatedNdk=trueファイルを作成して、プロジェクトをsyncする。local.propertiesファイルの修正4で、gradle.propertiesファイルを作成し、プロジェクトをsyncすると、次のエラーが発生する。ndkの絶対パス>を記述する。ビルド失敗に対する対策(openCVSamplefacedetectionのbuild.gradleを編集)プロジェクトをRebuildすると、次のエラーが発生する。Studioでのビルドで、Android.mkの設定が反映されないのが原因。ビルド時に、ndk-buildを実行するタスクを追加する。ファイル修正後、再度、Rebuild。Rebuild失敗に対する対策6で、openCVSamplefacedetectionのbukld.gradleの修正後、プロジェクトをRebuildすると、次のエラーが発生する。よると、OpenCVのsdkを、プロジェクトから認識できないのが原因で、openCVSamplefacedetection/src/main/jniにあるAndroid.mkファイルを次のように修正する。sdkの絶対パス>/sdk/native/jni/OpenCV.mkに修正する。修正後、Rebuild。ファイルが生成されれば、ビルドが成功する。アプリ実行アプリをRunすると、次のようなエラーが発生する。そこで、シンボリックをはる。Managerのインストールアプリを再度、Runする。Managerがインストールされていないので、インストールしろというメッセージが出る。Mangerをインストールする。アプリを再度、実行アプリが動作するようになる。6Pでは、logcatに次のエラーを出して、アプリが実行できない。64bitであるため。ファイルを次のように修正する。Clean、Rebuild。再度、アプリ実行する。はじめに以前、記事、ORMLiteを使ったアドレス帳アプリをテストしやすいように書き換え、Espressoでテストしたで、アドレス帳アプリの各種テストのやり方を書きました。その記事では、住友孝郎@cattaka_net氏のスライド開発を効率的に進めるられるまでの道程で紹介されているように、テスト時、データベースファイルを、RenamingDelegatingContextを使って、テスト用ファイルに置き換えて、各種テストを行いました。Androidを使うアプリの場合、Espressoを使ったUIのテスト時、ListViewの表示終了を待ってくれず、テストがうまくできませんでした。Androidの使用を断念して、従来のAsyncTaskLoaderを使用する方針に転換しました。2をデータベースに適用して、データベースの絡むUIテストはまだやっていませんでした。RenamingDelegatingContextを使えば、依存性注入をやることもないのですが、SharedPreferencesやネットワークアクセスAPIに依存性注入をやるようなアプリでは、データベースにも依存性注入をやって統一するのもいいのではないかと思います。テスト対象アプリテスト対象アプリは、andropenguin/AddressBookORMLite7ですが、画面遷移に、startActivityを使うのをやめ、Fragmentを使用することにしました。String)で取得することにしました。...}ActivityとFragmentクラスは次のとおりです。コンストラクタOpenHelperの第2引数には、mDatabaseNameを渡し、MainActivityでは、それは、DATABASE_NAMEであり、PersonListFragmentや、RegisterFragmentでは、MainActivity.DATABASE_NAMEです。依存性を見つける今回は、依存性注入を行い、テスト時に、データベースファイルをテスト用に置き換えたいので、MainActivity、PersonListFragment、RegisterFragmentのmDatabaseNameがStringに依存していることから、mDatabaseNameに依存性注入を行うことにしました。モジュールクラスプロダクションコードのモジュールクラスは次のとおりです。ここでは、provideDatabaseNameメソッドは、実際のデータベースファイルのファイル名を返します。}}テスト用のモジュールクラスは次のとおりです。付けたファイル名を返すようにして、mockModeがfalseの時は、実際のデータベースファイル名を返すようにしました。@Injectを付け、injectを呼ぶ次のように、MainActivity、PersonListFragment、RegisterFragmentクラスで、mDatabaseNameに、@Injectアノーテーションを付け、また、mDatabaseNameへの代入文をコメントアウトして、injectを呼びます。テスト用のベースinjectedクラスを作るInstrumentationTestCaseを使うクラスのために、debug/java配下に、次のクラスを作ります。cleanData();&#91;/java&#93;のように、後述で定義するAppクラスのインスタンスを取得して、setMockModeで、モックモードにして、injectで依存性注入を行います。OpenHelperコンストラクタの第二引数に、依存性注入されたmockDatabaseNameを渡します。上記コードのように、データベースをクリアするcleanDataメソッドと、ダミーデータをデータベースに作るcreateTestDataメソッドを定義しています。ActivityInstrumentationTestCase2を使うテストのために、debug/java配下に、次のクラスを作ります。}}&#91;/java&#93;依存性注入の仕方は、InjectedInstrumentationTestクラスと同様です。2は、タイプパラメータを持ったInjectedBaseActivityTestに依存性注入ができないようです。そこで、androidTest/java配下に、同じ内容のクラスInjectedBaseActivityTestを作ってみたのですが、後述のコンポネントクラスから、そのクラスInjectedBaseActivityTestが見えないようで、その方法を断念しました。InjectedBaseActivityTestクラスでも、データベースのデータをクリアするメソッドと、ダミーデーをデータベースに作るメソッドを定義しました。InjectedInstrumentationTestとコードのダブリがあるので、2つのメソッドをユーティリティクラスに抽出する試みをやったのですが、問題が生じてうまくいきませんでした。注意深くやればいいのかもしれませんが、それは宿題にします。2とEspressoを使ってUIテストをすると同様に、Applicationを継承したクラスAppを作り、マニフェストファイルに登録します。コンポネントクラスコンポネントクラスは次のとおりです。}}MainActivity、PersonListFragment、RegisterFragment、InjectedBaseActivityTest、InjectedInstrumentationTestの各クラスで、依存性注入を行うので、上記コードの通り、injectメソッドを定義します。テストクラスを作ります。mockDatabaseName);であったので、テスト用データベースファイルを使ってテストを行っています。テスト項目は次のとおりです。AdapterのテストAdapterのテストは、データベースを使わないので、ORMLiteを使ったアドレス帳アプリをテストしやすいように書き換え、Espressoでテストしたと同様にテストコードを書きます。AsyncTaskLoaderのテストAsyncTaskLoaderのテストコードは次のとおりです。}}今回は、AsyncTaskLoaderは、データベースからデータを読み込む処理に使い、テスト用データベースファイルを使いますので、テストクラスは、InjectedInstrumentationTestクラスを継承します。mockDatabaseName);とすることにより、PersonLoaderコンストラクタの第二引数には、テスト用データベースファイルのファイル名を渡しています。UIのテストUIのテストコードは次のとおりです。}}このクラスは、上で定義したInjectedBaseActivityTestクラスを継承していて、InjectedBaseActivityTestでは、mockDatabaseNameに依存性注入を行っているので、このテストクラスは、テスト用データベースファイルを使用しています。テスト項目は次のとおりです。今回作成したアプリのソースファイルを公開します。JapanのモバイルニュースのRSSを取得するアプリを作り、RxPressoでテストしてみたを書きました。Androidを使い、データをリスト表示するアプリで、開発を効率的に進めるられるまでの道程で紹介されている手法を使って、データベースファイルをテスト用のデータベースファイルに置き換えて、EspressoでUIテストを行おうとしたのですが、テストがListViewの表示終了を待ってくれず、UIのテストができませんでした。Resouceの実装がかなり難しいようです。Androidを使ったアプリは作れるようにはなったのですが、そのUIテストをするには学習コストがかなり高いようです。2で依存性注入を行い、ダミーデータを用いて、UIのテストを行ってみました。題材は、先日紹介したhttps://github.com/andropenguin/SladMobileRssReaderをAsyncTaskLoaderを使うように書き換えたものです。テスト対象アプリ記事一つひとつを表すクラスは次の通りです。}}今回は、例外のテストもできるように、結果データに対応する次のクラスを作りました。Rssリストの取得の成否を保持する。}}AsyncTaskLoaderを継承したクラスは、次の通りです。起動方法で紹介されている汎用的なクラスです。RssApiクラスは、次の通りで、String型の指定したurlから、ネットワークアクセスして、InputStreamを取得して、それをXmlでパースして返すクラスです。依存性を見つけるRssApiクラスを見ると、InputStreamやXmlデータに依存性を注入するのはテストがしにくいようです。RssListLoaderクラスを見ると、mRssDataが、RssDataに依存しています。RssDataクラスは、フィールドに、ListであるmItems、booleanであるmSuccess、StringであるmErrorMessageを持ち、これらは、容易にダミーデータに置き換えることができます。そこで、mRssDataに依存性注入を行うことにします。2で依存性注入を行い、テストしやすいコードを書きます。2を使ってSharedPreferencesのテストを行ってみたと同様に、build.gradle、app/build.gradleを編集します。モジュールクラスプロダクションコードのモジュールクラスは次のようになります。}}RssApiクラスは、コンストラクタにurlであるparamを必要とするので、RssDataModuleに、String型のparamを引数とするコンストラクタを定義しました。テスト用のモジュールクラスは、debug/java配下に置き、次のようになります。DebugRssDataModuleのコンストラクタは、モックモードの切り替えをするprovideMocksと、urlであるparamを引数に持ちます。モックモードの場合、provideRssDataメソッドは、mockを返し、そうでない場合は、実際に、インターネットにアクセスして取得したRssDataデータを返します。依存性注入を行うクラスRssListLoaderクラスは次のようになります。App.getInstance().component().inject(this);に書き換えることにより、依存性注入を行っています。このinjectは、RssListLoaderのコンストラクタ内で呼ぶと、android.os.NetworkOnMainThreadExceptionが発生します。時間のかかる処理は、loadInBackground内に書くべきだから、そうなんでしょう。2を使ってSharedPreferencesのテストを行ってみたと同様に、テストクラスが継承するInjectedBaseActivityTesクラスを、debug/java配下に置きます。コンポーネントクラスRssDataComponentクラスを、debug/java配下に置きます。}}DebugRssDataModuleクラスのコンストラクタは、paramを引数に持つようにしていたのですが、interfaceはコンストラクタを持てないので、paramをどう設定するかが悩みです。paramを定数フィールドにするのは手ではありますが、urlをinterfaceで固定するのはいい設計ではないです。}を定義し、Initializerクラスでは、RssListFragment#getParamメソッドを呼ぶことにより、paramを取得し、DebugRssDataModuleのコンストラクタに渡すことにしました。AppクラスAppクラスを、プロダクションコードに置きます。}}Appをマニフェストファイルに登録します。テストクラス次のテストクラスを、androidTest/java配下に置きます。}}テストしたケースは次の通りです。IOExceptionやXmlPullParserExceptionの例外が発生した時、Toastが表示されるかUIのテスト時は、ダミーのデータを使用するため、createDummyItems、createDummyRefreshItemsメソッドを定義しています。InjectedBaseActivityTestで、@Injectアノーテーションを付けたので、mockRssDataを使ってテストをします。DebugRssDataModuleクラスで定義したように、テスト時は、モックモードになっており、RssDataはmockになっています。getItemsとisSuccessに対して値を返すようにして、UIのテストを行っています。更新ボタンを押した時のテストも同様に行います。isSuccessとgetErrorMessageに対して値を返すようにして、UIのテストを行っています。本記事で扱ったサンプルプロジェクトを公開します。Patternsが詳しい。Androidを使用したアプリのUIテストを容易に行うことができるそうなので、RxPressoを使用してみた。JapanのモバイルニュースのRSSを取得して、リスト表示、リストの行をタップすると、ニュース詳細を見れるサンプルアプリを作成し、また、RxPressoとEspressを使用して、UIのテストを行った。app/build.gradleの編集dependenciesに次の行を追加します。}また、このままだとビルドエラーが起きるので、androidブロックに、次の記述を追加します。記事一つひとつに対するItemクラスを定義します。持たせ、セッター、ゲッターを定義しました。RssDataを作ります。}}セッターとゲッターを定義しています。APIを定義するinterfaceを作るRSSデータ、RssDataを、メソッド名は、getRssDataとします。引数は、urlなので、String型とします。Androidを使用するために、次のinterfaceを定義します。Androidを使用するため、RssDataをObservableで包んでいます。interfaceを実装する5で定義したinterfaceを実装します。}}ここで、interfaceで定義したgetRssDataメソッドを次のように実装しています。StudioやIntelliJのコード補完で容易にコードを書くことができるはずです。このコードでは、paramで指定されたurlからInputStreamを取得し、Xmlでパースし、結果、ListをRssData型にしています。onNextに渡しています。onNextはひとつの値の処理が終わるたびに実行されます。IOExceptionや、XmlPullParserExceptionの例外が起きた場合は、例外をonErrorに渡します。RSSリーダーの要、パース機能を知るの記事を参考にしました。Androidを利用して定義したメソッドにアクセスできるように、Applicationクラスを継承したクラスAppを定義します。}}プロダクションコード、テストコードの両方から、Appインスタンスを取得できるように、Appインスタンスを返すgetInstanceメソッドを定義しています。ConcreteDataRepositoryのインスタンスを入れます。App.getInstance().getRepository();とすることにより、dataRepositoryにConcreteDataRepositoryのインスタンスを入れ、テスト時には、setRepositoryメソッドを呼ぶことにより、テスト用のDataRepositoryを使用するようにします。Manifestファイルに、このAppを登録しておきます。これを忘れると、アプリが落ちるし、テストもできません。あと、ネットワークにアクセスするので、パーミッションも追加しておきます。Androidを利用します。RssListFragmentクラスを次のように実装します。App.getInstance().getRepository();によって、プロダクション用ConcreteDataRepositoryインスタンスをdataRepoitoryに入れています。することにより、6で定義した、プロダクション用getRssDataを呼ぶことができます。Androidを使用しているコードは、次の部分です。Operatorで加工した値を受け取るRssDataObserverクラスのそれぞれのメソッドでは、データを加工します。例外の場合、onErrorで、setErrorメソッドを呼び、Toastを表示します。onNextでは、一つのの値が終わるたびに実行されるので、setRssResultメソッドが呼ばれ、本アプリでは、リスト更新がされます。};のように記述します。InstrumentationRegistry.getTargetContext().getApplicationContext()で、Appインスタンスを取得し、RxMocksのmockメソッドで、DataRepositoryのモックを取得、App#setRepositoryメソッドを呼ぶことにより、モックを利用する設定を行います。RxPressoのインスタンスを取得して、EspressoのregisterIdlingResourcesにより、IdlingResourceを登録します。afterActivityFinishedで、IdlingResourceの登録解除を行います。テストの内容の説明テストでは、実際にインターネットにアクセスしてRSSデータを取得すのではなく、次のコードの通り、RssDataをmockに置き換え、それのgetIemsメソッドがダミーデータを返すようにして、ダミーのデータで、UIのテストを行います。when(mockRssData.getItems()).thenReturn(items);テスト項目は次の通りです。リストの行数のテスト。更新ボタンを押したら、リストが正しく更新されるかのテストリストの行数のテスト。リストの各行の内容表示のテストのコードは次の通りです。