Androidプラットフォームの開発に慣れていない場合は、新しいGTestバイナリ（「ネイティブ」テストとも呼ばれる）を最初から追加するこの完全な例が、関連する一般的なワークフローを示すのに役立つ場合があります。 C ++用のGTestフレームワークの詳細については、 GTestプロジェクトサイトで追加のドキュメントを参照してください。
このガイドでは、例としてHelloWorldGTestを使用します。続行する前に、コードを読んで大まかに理解することをお勧めします。
ソースの場所を決定する
通常、チームには、コードをチェックインする場所とテストを追加する場所のパターンがすでに確立されています。ほとんどのチームは単一のgitリポジトリを所有しているか、他のチームと共有していますが、コンポーネントのソースコードを含む専用のサブディレクトリを持っています。
コンポーネントソースのルートの場所が<component source root>であると仮定すると、ほとんどのコンポーネントにはsrcフォルダーとtestsフォルダーがあり、 Android.mkなどの追加ファイル（または追加.bpファイルに分割）があります。
新しいテストを追加するため、コンポーネントsrcの横にtestsディレクトリを作成し、コンテンツを入力する必要があります。
場合によっては、さまざまなテストスイートを個々のバイナリにパッケージ化する必要があるため、チームでtests中のディレクトリ構造がさらに増える可能性があります。この場合、 tests対象の新しいサブディレクトリを作成する必要があります。
説明のために、単一のtestsフォルダを持つコンポーネントの一般的なディレクトリの概要を次に示します。
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- src (test source)
\-- foo_test.cpp
\-- ...
複数のテストソースディレクトリを持つコンポーネントの一般的なディレクトリの概要は次のとおりです。
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- testFoo (sub test source root)
| \-- Android.bp (sub test makefile)
| \-- src (sub test source)
| \-- test_foo.cpp
| \-- ...
\-- testBar
| \-- Android.bp
| \-- src
| \-- test_bar.cpp
| \-- ...
\-- ...
構造に関係なく、 testsディレクトリまたは新しく作成されたサブディレクトリに、サンプルのgerritchangeのnativeディレクトリにあるものと同様のファイルを入力することになります。以下のセクションでは、各ファイルの詳細について説明します。
ソースコード
例については、 HelloWorldGTestを参照してください。
その例のソースコードはここに注釈が付けられています：
#include <gtest/gtest.h>
GTestのヘッダーファイルインクルード。インクルードファイルの依存関係は、makefileでBUILD_NATIVE_TESTを使用して自動的に解決されます。
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTestは、 TESTマクロを使用して記述されます。最初のパラメーターはテストケース名で、2番目のパラメーターはテスト名です。テストバイナリ名とともに、結果ダッシュボードで次の階層を形成します。
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
GTestを使用したテストの作成の詳細については、GTestのドキュメントを参照してください。
簡単な設定ファイル
新しい各テストモジュールには、モジュールメタデータ、コンパイル時の依存関係、およびパッケージ化手順を使用してビルドシステムに指示する構成ファイルが必要です。ほとんどの場合、Soongベースのブループリントファイルオプションで十分です。詳細については、単純なテスト構成を参照してください。
複雑な構成ファイル
代わりにTradeFederationを使用するには、AndroidのテストハーネスであるTradeFederationのテスト構成ファイルを作成します。
テスト構成では、特別なデバイスセットアップオプションとデフォルトの引数を指定して、テストクラスを提供できます。
ローカルでビルドしてテストする
最も一般的なユースケースでは、 Atestを使用します。
より重いカスタマイズが必要なより複雑なケースについては、インストルメンテーションの指示に従ってください。