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.