Starting March 27, 2025, we recommend using android-latest-release
instead of aosp-main
to build and contribute to AOSP. For more information, see Changes to AOSP.
Structure of a test runner
Stay organized with collections
Save and categorize content based on your preferences.
The test runner is the execution unit of the invocation flow. This is where
tests actually run.
Interfaces
Test runners are defined via the IRemoteTest
interface,
which provides a simple run
method to implement that will be called when the
tests is to run.
This allows the simplest definition of a test run to occur. But in practice,
test writers will need more information to properly write their tests, typically
build and device information. This is where the following interfaces come handy.
Basic
These two interfaces are the most widely used today, as they represent the basic
needs of most tests.
- IBuildReceiver
allows the test to get the
IBuildInfo
object created at the build
provider step
containing all the information and artifacts related to the test setup.
- IDeviceTest
allows TF to receive the
ITestDevice
object that represents the device
under test and provides an API to interact with it.
Advanced
There are additional interfaces that allow more complex interaction between the
test harness and the test runner:
- ITestFilterReceiver,
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.
- ITestCollector,
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.
Existing test runners
A variety of test runners already exists, some for major test types:
A large number of custom test runners exist besides the above; they serve
specialized purposes for some functional testing, for example Boot Test.
Write a new test runner
More guidance of writing a new test runner is available in the writing tests
section.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-06-18 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-06-18 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)."]]