2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
テストランナーの構造
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
テストランナーは、呼び出しフローの実行ユニットです。そこで実際にテストが実行されます。
インターフェース
テストランナーは IRemoteTest インターフェースによって定義されます。このインターフェースはシンプルな run
メソッドを提供し、テストの実行時にはこのメソッドが呼び出されます。
これにより、実行するテストの最も簡単な定義ができます。しかし、実際にテストを作成するには、ビルドやデバイスの情報など、テストを適切に記述するためにさらに詳しい情報が必要になります。そのための便利なインターフェースを次に挙げます。
基本的なインターフェース
次の 2 つのインターフェースは、ほとんどのテストの基本的なニーズに対応しているため、現在最も広く使用されています。
- IBuildReceiver: ビルド プロバイダ ステップで作成された
IBuildInfo
オブジェクトをテストに取り込めます。これにはテストのセットアップに関連するすべての情報とアーティファクトが含まれています。
- IDeviceTest: テスト対象のデバイスを表し、そのデバイスを操作する API を提供する
ITestDevice
オブジェクトを TF が受信できるようにします。
高度なインターフェース
追加のインターフェースとして、テストハーネスとテストランナー間でより複雑なやり取りができるものがあります。
- ITestFilterReceiver: 特定のテストのみを実行するフィルタのセットをテストで受け取れます。これは、テストのサブセットを実行するときに役立ちます。
- ITestCollector: テストランナーが実際にテストを実行する代わりに、テストのドライランのみを実行できるようにします。これは、すべてのテストケースのリストを収集するときに役立ちます。
既存のテストランナー
さまざまなテストランナーが存在します。主なテストタイプは次のとおりです。
上記以外にも、起動テストなどの機能テストに特化した多数のカスタム テストランナーが存在しています。
新しいテストランナーを作成する
新しいテストランナーの作成についての詳しいガイダンスは、テストの作成に関するセクションをご覧ください。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-26 UTC。"],[],[],null,["# Structure of a test runner\n\nThe test runner is the execution unit of the invocation flow. This is where\ntests actually run.\n\nInterfaces\n----------\n\nTest runners are defined via the [IRemoteTest\ninterface](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/invocation_interfaces/com/android/tradefed/testtype/IRemoteTest.java),\nwhich provides a simple `run` method to implement that will be called when the\ntests is to run.\n\nThis allows the simplest definition of a test run to occur. But in practice,\ntest writers will need more information to properly write their tests, typically\nbuild and device information. This is where the following interfaces come handy.\n\n### Basic\n\nThese two interfaces are the most widely used today, as they represent the basic\nneeds of most tests.\n\n- [IBuildReceiver](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/IBuildReceiver.java) allows the test to get the `IBuildInfo` object created at the [build\n provider](/docs/core/tests/tradefed/architecture/build-provider) step containing all the information and artifacts related to the test setup.\n- [IDeviceTest](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/IDeviceTest.java) allows TF to receive the `ITestDevice` object that represents the device under test and provides an API to interact with it.\n\n### Advanced\n\nThere are additional interfaces that allow more complex interaction between the\ntest harness and the test runner:\n\n- [ITestFilterReceiver](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/ITestFilterReceiver.java), which allows the test to receive a set of filters for running certain tests only. This is useful in running a subset of the tests.\n- [ITestCollector](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/ITestCollector.java), which allows a test runner to only dry-run the tests instead of actually executing them. This is useful in collecting the list of all test cases.\n\nExisting test runners\n---------------------\n\nA variety of test runners already exists, some for major test types:\n\n- [AndroidJUnitTest / InstrumentationTest](/reference/tradefed/com/android/tradefed/testtype/AndroidJUnitTest) (associated with AJUR on the device side)\n- [GTest](/reference/tradefed/com/android/tradefed/testtype/GTest) (device and host side) with [googletest library](https://github.com/google/googletest)\n- [Host-driven\n tests](/reference/tradefed/com/android/tradefed/testtype/HostTest) (Java tests that execute on the host and call the device from there)\n- [Pure Java unit\n tests](/reference/tradefed/com/android/tradefed/testtype/HostTest) (our runner does both)\n- [Python tests](/reference/tradefed/com/android/tradefed/testtype/python/PythonBinaryHostTest)\n- [Google Benchmark\n tests](/reference/tradefed/com/android/tradefed/testtype/GoogleBenchmarkTest) with [benchmark library](https://github.com/google/benchmark)\n\nA large number of custom test runners exist besides the above; they serve\nspecialized purposes for some functional testing, for example Boot Test.\n\nWrite a new test runner\n-----------------------\n\nMore guidance of writing a new test runner is available in the [writing tests\nsection](/docs/core/tests/tradefed/testing/through-tf/new-test-runner)."]]