テストは、アプリケーション開発の最も重要なステップの1つです。 そして、Androidアプリも例外ではありません。 コードを書くときは、通常、それを見て、後でテストする方法を考える必要があります。 完全に記述されたプロジェクトをテストする必要がある状況を想像してください。 多くの場合、それほど簡単ではありません。 ほとんどの場合、テストしやすいように、コードは単に実装されていないだけです。 これは、機能を破壊せずにテストできるように変更する必要があることを意味します（実際には、これはリファクタリングと呼ばれます）。 しかし、そのような変更を行うと、包括的なテストがない場合、作業中のコードで何も壊さなかったと迅速かつ自信を持って言うことができますか？ ほとんどない。 テスト、つまりUNITテストは、開発者自身が記述する必要があります。開発者と彼だけが、どのように、何を書くかについてすべてを知っているからです。
Androidに関しては、他のすべての人と同様に、Googleは悪いテストツールを提供していませんでしたが、すべてをそれらで実行できるわけではありません。 テストには、長所と短所があるjUnitフレームワークが使用されます。
jUnit-単体テストに使用されます。これにより、プログラムのソースコードの個々のモジュールの正確性を確認できます。 このアプローチの利点は、単一のモジュールを他のモジュールから分離できることです。 同時に、このメソッドの目的により、プログラマーはモジュール自体が正しく動作することを確認できます。 jUnitはクラスライブラリです。 しかし、おそらくこのフレームワークを使用してテストを書いた人は、GUIをテストするとき、それが完全に不便であることを確認したでしょう。 良い味の兆候は、テストでカバーされているコードと、テストでコードがカバーされている割合を示すレポートです。 最近、プロジェクトでは、特にロードからGUIまでのテストを作成する必要があり、私が満たす機能とこれらのレポートの作成方法についてお話したいと思います。 しかし、最初に、メインフレームワークについて：
メインフレームワークの使用の概観。 実際、彼自身のそれぞれの選択がします。 直観的なインターフェイスのために、誰かがEspressoのようにソースコードに乗りたがらないためにRobotiumを選択します。
スプーン
スプーンは、テストの実行中にデバイスまたはエミュレーターの画面からスクリーンショットを取得し、結果としてそれらからレポートを作成できるフレームワークです。 スクリーンショットに加えて、彼はテストランナーのログをレポートに添付し、テストが失敗した場合、完全なスタックトレースを表示します。これは非常に便利です。 レポートを取得するには、次を実行します。
- Spoon-clien tとSpoon-runnerをダウンロードしてください。
- Spoon-clientをテスト付きのプロジェクトのlibsフォルダーにコピーします。
- 同じプロジェクトで、フォルダー（スプーンなど）を作成します。
- Spoon-runnerを作成されたフォルダーにコピーします。
- 次のスクリプトを使用してbatファイルを作成します。
call java -jar spoon-runner-1.1.1-jar-with-dependencies.jar -- apk Path\to\your\project \bin\project.apk -- test-apk Path\to\your\test-project \bin\tests.apk
サブパラメーターでは、テスト用のフィルターを指定できます。たとえば、スクリプトにサイズmediumを追加することにより、「Medium」注釈が付いたテストのみを実行できます。
これで、スクリプトは次のようになります。
call java -jar spoon-runner-1.1.1-jar-with-dependencies.jar -- apk Path\to\your\project \bin\project.apk -- test-apk Path\to\your\test-project \bin\tests.apk -- size medium
サブパラメーターの完全なリストは、 Githubの公式ページにあります。 テストを作成するときに、必要な場所にすべてを挿入します。
Spoon.screenshot(activity, "state_changed"),
2番目の引数は、スクリーンショットの上に強調表示される行です。 はい、別の機能-その内部では正規表現を使用し、署名でスペースを使用すると例外がスローされます。 エミュレーターを起動するか、電話を接続し、バッチファイルを開きます。すべてが正常に完了すると、同じフォルダーにレポートが表示されます。
開発者からのレポートの公式例はこちらです。
私のプロジェクトからのレポートはここで見ることができます 。
悪くないですか？ 「スプーン」のもう1つの利点は、接続されているすべてのデバイスで同時にテストを実行することです。つまり、1つのレポートですべてのデバイスから結果を収集します。 唯一の、そしておそらく重要なマイナス点は、ダイアログのスクリーンショットを撮らないことと、テスト中に何が表示されたかを見ることができないことです。 そして、彼はまだテストでコードカバレッジに関するレポートを作成しません！ さて、それを修正しましょう。
エマ
同意して、報告書は少なくとも価値があるように見える
テストでカバーされたコードの例：
それぞれ部分的にカバーされています：
すべての形式の完全なレポート。
EMMAは、Javaでのテスト範囲を測定および報告するためのオープンソースのツールキットです。 このツールはAndroid SDKに組み込まれており、開発者は「そのまま」レポートを生成する機能を提供します。 主な機能：
- オフラインモード（ロード前）およびオンザフライでのクラス検査のサポート。
- サポートされるカバレッジタイプ：パッケージ、クラス、メソッド、ライン、およびメインユニット。 また、ソースコードの1行が部分的にしかカバーされていないことを検出することもできます。
- 出力レポートのタイプ：テキスト、HTML、XML。
Antを使用してプロジェクトを構築する
Apache Antは、開発構造をアプリケーション展開設計に変換するためのツールです。 これは宣言型であり、アプリケーションの展開に使用されるすべてのコマンドライン命令は、単純なXML要素で表されます。 詳細はこちらをご覧ください 。
プロジェクトのアセンブリ手順を説明するには、次のものが必要です。作業中のプロジェクト-MyProjectおよびテスト用のプロジェクト-MyProjectTests。 ここでテストを作成するときに従わなければならない規則について読むことができます 。
まず、Antを使用してプロジェクトをビルドする場合、アプリケーションでライブラリとして使用されるプロジェクトを収集する必要があります。 ない場合は、この手順をスキップできます。 たとえば、プロジェクトで「google_play_service_lib」などのライブラリを使用する場合は、次を実行する必要があります。
-コマンドラインで、sdk \ tools（たとえば、D：\ android \ adt-bundle \ sdk \ tools）がインストールされているフォルダーに移動して、次を実行します。
android update lib-project -p MyLibProject
、ここでMyLibProjectはプロジェクトで使用されるライブラリへのパスです。 その結果、build.xmlがプロジェクトルートに表示され、コンソールにメッセージが表示されます。
Updated local.properties Updated file D:\Workspace\MyProject\build.xml Updated file D:\Workspace\MyProjectTests\proguard-project.txt
すべてのライブラリをアセンブルした後、作業プロジェクト自体をアセンブルする必要があります。 これを行うには、同じフォルダ内で次を実行する必要があります。
android update project -p MyProject
MyProjectは、プロジェクト作業ブランチへのパスです。 当然、AndroidManifest.xmlはこのフォルダーにあります。 スクリプトはbuild.xmlを再度生成し、作業中のプロジェクトをビルドします。 サブパラメーターを使用してプロジェクトの名前を入力できるため、後で使用するのに便利です。
android update project -p MyProject -n NameForProject
プロジェクトはどのようにテストでビルドされますか？ すべてが同様で便利です。 テスト付きのプロジェクトをビルドするためのスクリプト：
android update test-project -m ..\MyProject -p \MyProjectTests
、ここでMyProjectは作業中のプロジェクトへのパス、MyProjectTestsはテストを含むプロジェクトへのパスです。
すべて準備完了です！ ところで、このステップでは、開発者がライブラリを使用しているために問題が発生する可能性があります！ たとえば、プロジェクトでは、他のライブラリで使用されているライブラリに基づいてさまざまなjarライブラリをコンパイルできます。 Antはそれらの処理方法を理解していないため、アセンブリ中にエラーが発生します。 つまり、1つの同じライブラリがプロジェクト内で使用されている場合、これはすでにエラーにつながる可能性があります。
スクリプト内のテストによるコードカバレッジの量の計算を開始するには、サブパラメーターにemmaを登録する必要があります。 開始する前に、エミュレータを実行するか、デバイスを接続する必要があります。 次のスクリプトは、テストを含むプロジェクトの最上位ブランチのコマンドラインで実行されます。
ant clean emma debug install test
テスト中に、Emmaはメインプロジェクト（メタデータ）のbinフォルダーにcoverage.emファイルを生成し、すべてのテストが必要な権限を設定した後、インストールされたプロジェクトのフォルダーにcoverage.ecファイルを作成し、これら2つのファイルをテストプロジェクトのbinフォルダーにコピーし、それらに基づいて、同じフォルダにレポートを生成します。
サンプルレポートを含む私のプロジェクトのソースは、 Githubにあります。
まとめると
非常にうまく書かれていても、テストを見てみましょう。 あなたは彼らを見て、彼らがあなたのコードをどれだけカバーしているかに答えることができますか？ テストの結果を全体として視覚的なレポートとして表示する緑色のストリップがあれば十分ですか？ 私はそうは思いません。 作業の結果としてレポートを使用すると、スペシャリストの能力レベルが示され、テストの自動化に関してはさらに重要です。 スクリプトを書くのは確かに時間がかかりますが、私を信じて、それは価値がある！