This page tells you how to write a host-side test that doesn't require a device, such as a test that runs on a Linux GCE instance. (For details about writing a host-driven test that requires a device, refer to Write a Host-driven Test in Trade Federation.)
Host-side test types
You can run several types of host-side tests through Trade Federation (TF).
Native (gtest) tests
Create Native tests (gtests) to test a platform. If the test doesn't require a device, run it on a host; the test will run much faster that way. To configure such tests to run on a test host, use the TF runner HostGTest.
This is a sample TradeFed test configuration:
<configuration description="Runs hello_world_test."> <option name="null-device" value="true" /> <test class="com.android.tradefed.testtype.HostGTest" > <option name="module-name" value="hello_world_test" /> </test> </configuration>
The test configuration runs a gtest test (hello_world_test) on a host. The example test config can be auto-generated. Unless your test needs a special setup or cleanup, you can rely on auto test-config generation to create proper TF test configurations.
To configure a host-side gtest and enable auto test- config generation, set
host_supported to true in
Android.bp, as in hello_world_test.
For more information about writing a native test, see Adding a New Native Test Example.
JAR host tests
JAR (Java) host tests, such as JUnit, are tests that don't need to run on a device, and that provide code coverage of your Java project. Such tests can be configured to run on a test host by using the runner HostTest.
Sample TradeFed test configuration
<configuration description="Executes HelloWorldHostTest"> <test class="com.android.tradefed.testtype.HostTest" > <option name="jar" value="HelloWorldHostTest.jar" /> </test> </configuration>
The test configuration runs a host-side JUnit test of HelloWorldHostTest. Note that the above test configuration can be auto-generated. Unless your test needs special setup or cleanup, rely on the auto test-config generation to create proper TradeFed test configuration.
For more details about how to write a JAR host test, refer to the JAR (Java) Host Tests page.
Isolated Java host tests
Deviceless Java tests can be run in an isolation environment with a slight performance cost. However, there are some major considerations to be made before choosing to use this environment.
- This is the default runner used for Robolectric and JUnit unit tests
 - Tradefed supports only JUnit tests in the isolation environment.
 - Only statically linked dependencies are supported. No dependencies declared
    with 
libare included on the classpath. - The isolation runner only puts the shim runner and your test jar on the classpath.
 - There is some amount of fixed overhead per test run executed with this runner.
 
Sample Tradefed test configuration (isolated)
<configuration description="Executes HelloWorldHostTest"> <test class="com.android.tradefed.testtype.IsolatedHostTest" > <option name="jar" value="HelloWorldHostTest.jar" /> </test> </configuration>
Sample Soong configuration for autogeneration
Instead of manually creating the test config like above, Soong can autogenerate the config by using a declaration like this example.
java_test_host {
    name: "HelloWorldHostTest",
    test_options: {
        unit_test: true,
    },
    test_suites: ["general-tests"],
    srcs: ["test/**/*.java"],
    static_libs: [
        "junit",
    ],
}Robolectric tests
Robolectric tests use the same runner as the isolated host tests, with a few special options.
- The 
robolectric-resourcesoption enables a few Robolectric-specific command line options to be passed into the subprocess as well as adds the tree build ofandroid-allto the subprocess classpath. While the other two are best practices, this option is mandatory for running Robolectric tests with any success. - The 
java-folderoption allows changing the Java runtime used by the subprocess. This is necessary due to Robolectric preferring particular Java versions that might not align with the host system's preferred JVM. - The 
exclude-pathsoption allows the subprocess runner to avoid loading particular modules at all, which is useful when a JAR comes with extraneous classes that could cause load errors.java.is a common exclusion, to avoid throwingSecurityExceptionexceptions. 
Sample Robolectric config
<configuration description="Executes a Sample Robolectric Test"> <option name="java-folder" value="prebuilts/jdk/jdk9/linux-x86/" /> <option name="exclude-paths" value="java" /> <option name="use-robolectric-resources" value="true" /> <test class="com.android.tradefed.testtype.IsolatedHostTest"> <option name="jar" value="RobolectricExampleTest.jar" /> </test> </configuration>
Sample Soong configuration for Robolectric autogeneration
Instead of manually creating the test config like above, Soong can autogenerate the config by using a declaration like this example.
android_robolectric_test {
    name: "HelloWorldRoboTest",
    srcs: [
        "src/**/*.java",
    ],
    // Include the testing libraries
    static_libs: [
        "mockito-robolectric-prebuilt",
        "platform-test-annotations",
        "testng",
        "truth-prebuilt",
    ],
    instrumentation_for: "HelloWorldApp",
}Python test
If the test logic is written in Python, use build type python_test_host to create a par file that can be
run by TF PythonBinaryHostTest.
Sample TradeFed test configuration
<configuration description="Config to run atest unittests"> <test class="com.android.tradefed.testtype.python.PythonBinaryHostTest" > <option name="par-file-name" value="atest_unittests" /> <option name="test-timeout" value="2m" /> </test> </configuration>
Test suite setting
For the host-side test to be accessible by TF for a given build, set the
test module `test_suites` setting to
`general-tests`:
test_suites: ["general-tests"],
With this setting, the test is packaged to general-tests.zip on
the test_suites target.