Android プラットフォーム開発を初めて行う場合は、以下に示す、新しい GTest バイナリ（「ネイティブ」テストとも呼ばれます）の追加をゼロから始める例が役に立ちます。この例には、一般的なワークフローが網羅されています。C++ の GTest フレームワークの詳細については、GTest プロジェクト サイトで追加のドキュメントをご覧ください。
このガイドでは、Hello World GTest を例として使用します。先に進む前に、コードに目を通し、コードの概要を理解することをおすすめします。
ソースの場所を決定する
通常、コードをチェックインする場所とテストを追加する場所はすでにチームで決まっています。ほとんどのチームは git リポジトリを 1 つ所有しているか、他のチームと共有しているが専用のサブ ディレクトリ（コンポーネントのソースコードが含まれる）を持っています。
コンポーネントのソースのルートが <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
| \-- ...
\-- ...
構造にかかわらず、サンプルにおける gerrit 変更の native ディレクトリ下にあるファイルと同様のファイルを tests ディレクトリや新しく作成されたサブ ディレクトリに追加します。以下のセクションでは、各ファイルについて詳しく説明します。
ソースコード
例については、Hello World GTest をご覧ください。
この例のソースコードは以下のとおりです。
#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 ベースのブループリント ファイル オプションで十分です。詳しくは、シンプルなテスト構成をご覧ください。
複雑な構成ファイル
代わりに Trade Federation を使用するには、Android のテストハーネスである Trade Federation のテスト構成ファイルを作成します。
テスト構成では、特別なデバイス セットアップ オプションとデフォルト引数を指定して、テストクラスを提供できます。
ローカルでのビルドとテスト
最も一般的なユースケースでは、Atest を使用します。
より多くのカスタマイズが必要な複雑なケースでは、インストルメンテーションの手順を実施してください。