En esta página, se proporciona información básica sobre cómo compilar un módulo rust_test que use el agente de prueba de Rust.
Cómo crear una prueba básica de Rust
Para ver un ejemplo en vivo de una prueba de Rust en el dispositivo y en el host, consulta keystore2 Android.bp o busca uno en varios de los contenedores del directorio external/rust/crates.
Un módulo rust_test compila con la marca --test de rustc, que crea pruebas a partir del código marcado con el atributo #[test]. Para obtener más información, consulta la documentación de los atributos de prueba de referencia de Rust.
Define un módulo de prueba de la siguiente manera:
rust_test {
name: "libfoo_inline_tests",
// Specify the entry point of your library or binary to run all tests
// specified in-line with the test attribute.
srcs: ["src/lib.rs"],
// Tradefed test suite to include this test in.
test_suites: ["general-tests"],
// Autogenerate the test config
auto_gen_config: true,
rustlibs: [
"libfoo",
],
}
El archivo TEST_MAPPING contiene una lista de pruebas. Aunque no es un requisito, si creas un archivo TEST_MAPPING, las pruebas que incluyas en él se ejecutarán en pruebas de envío previo y se podrán invocar mediante atest.
Puedes consultar la documentación de TEST_MAPPING, pero para el ejemplo de libfoo_inline_tests, agrega esto al envío previo a fin de habilitar tus ejecuciones de prueba en TreeHugger:
{
"presubmit": [
{
"name": "libfoo_inline_tests",
},
]
}
Ten en cuenta que los módulos rust_test_host se ejecutan de forma predeterminada en el envío previo, a menos que unit_tests: esté configurado como false, por lo que no es necesario declararlos en archivos TEST_MAPPING.
Para saber cómo funcionan las propiedades auto_gen_config y test_suites, consulta la sección sobre configuración de la documentación del flujo de trabajo del desarrollo de pruebas.
Propiedades notables de prueba de Rust
Los módulos rust_test heredan propiedades de los módulos rust_binary, como se describe en la página Módulos binarios.
Las propiedades que se definen en la siguiente tabla se agregan a las propiedades comunes importantes que se aplican a todos los módulos. Estas son particularmente importantes para los módulos de prueba de Rust o presentan un comportamiento único específico para el tipo de módulo rust_test.
- test_harness: Uso avanzado; el valor predeterminado es verdadero.
Configúralo como falso si tu rust_test implementa su propio agente de prueba y no necesitas usar el agente de prueba integrado de Rust (en otras palabras, si lo configuras como falso, no se pasará la marca --test a rustc).
Cómo evitar la duplicación entre rust_library y rust_test
Cuando usas pruebas de Rust intercaladas mediante módulos anidados, obtienes una duplicación en tu archivo Android.bp. El problema es que debes enumerar las dependencias dos veces, una para rust_library y otra para rust_test:
rust_library {
name: "libfoo",
srcs: ["src/lib.rs"],
rustlibs: [
"libx",
"liby",
"libz",
],
}
rust_test {
name: "libfoo_inline_tests",
srcs: ["src/lib.rs"],
test_suites: ["general_tests"],
rustlibs: [
"libx",
"liby",
"libz",
],
}
Cada módulo rust_test terminará enumerando las mismas dependencias que el módulo rust_library correspondiente. Para garantizar la coherencia entre los módulos, puedes enumerar las dependencias una sola vez en un módulo rust_defaults:
rust_defaults {
name: "libfoo_defaults",
srcs: ["src/lib.rs"],
rustlibs: [
"libx",
"liby",
"libz",
],
}
rust_library {
name: "libfoo",
defaults: ["libfoo_defaults"],
}
rust_test {
name: "libfoo_inline_tests",
defaults: ["libfoo_defaults"],
test_suites: ["general_tests"],
}
De esta manera, la biblioteca y el módulo de prueba siempre usarán las mismas dependencias.