Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

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

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.bp (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.bp (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/master/googletest/docs/Primer.md

シンプルな構成ファイル

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

複雑な構成ファイル

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

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

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

最も一般的な使用例の場合、Atest を使用します。

より複雑なカスタマイズが必要な場合は、インストゥルメンテーションの手順に従います。