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 escribir una prueba básica de Rust
Para ver un ejemplo en vivo de una prueba de Rust integrada 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 con atest.
Puedes consultar la documentación de TEST_MAPPING, pero para el ejemplo de libfoo_inline_tests, agrega esto al envío previo para 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 a través de 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.