新しいネイティブ テストの追加の例

Android プラットフォーム開発を初めて行う場合は、以下に示す、新しいネイティブ テストの追加をゼロから始める例が役に立ちます。この完全な例には、一般的なワークフローが含まれています。また、C++ の gtest フレームワークにも慣れていない場合は、gtest プロジェクト サイトで追加のドキュメントをご覧ください。

このガイドでは、次のテストを例として使用します。

Hello World ネイティブ テスト

先に進む前に、まずコードを確認して、おおよそのイメージをつかむことをおすすめします。

ソースの場所を決定する

通常、コードをチェックインする場所とテストを追加する場所はすでにチームで決まっています。ほとんどのチームは 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 ネイティブ テストの例をご覧ください。

アノテーション付きソースコードを以下に示します。

#include <gtest/gtest.h>

gtest ヘッダー ファイルのインクルード。インクルード ファイルの依存関係は、makefile で BUILD_NATIVE_TEST を使用すると自動的に解決されます。

#include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}

gtests は TEST マクロを使用して作成されます。最初のパラメータはテストケース名、2 番目はテスト名です。テストバイナリ名とともに、結果ダッシュボードで可視化した場合、以下のような階層になります。

<test binary 1>
| \-- <test case 1>
| |   \-- <test 1>
| |   \-- <test 2>
| |   \-- ...
| \-- <test case 2>
| |   \-- <test 1>
| |   \-- ...
| \-- ...
<test binary 2>
|
...

gtest を使用したテストの作成方法については、以下のドキュメントをご覧ください。

  • https://github.com/google/googletest/blob/main/docs/primer.md

シンプルな構成ファイル

新しいテスト モジュールごとに、モジュール メタデータ、コンパイル時の依存関係、パッケージ化手順をビルドシステムに指示するための構成ファイルが必要です。ほとんどの場合、Soong ベースのブループリント ファイル オプションで十分です。詳しくは、シンプルなテスト構成をご覧ください。

複雑な構成ファイル

代わりに Trade Federation を使用するには、Android のテストハーネスである Trade Federation のテスト構成ファイルを作成します。

テスト構成では、特別なデバイス セットアップ オプションとデフォルト引数を指定して、テストクラスを提供できます。

ローカルでのビルドとテスト

最も一般的なユースケースでは、Atest を使用します。

より多くのカスタマイズが必要な複雑なケースでは、インストルメンテーションの手順を実施してください。