Esta página proporciona información básica sobre cómo crear un módulo rust_test que utiliza el arnés de prueba de Rust.
Escribe una prueba básica de Rust
Para ver un ejemplo en vivo de una prueba de Rust en el dispositivo y en el host, consulte keystore2 Android.bp o ubique una entre muchas de las cajas en el directorio external/rust/crates .
Un módulo rust_test se construye utilizando el indicador --test de Rustc, que crea pruebas a partir del código marcado con el atributo #[test] . Para obtener más información, consulte la documentación sobre los atributos de prueba de referencia de Rust .
Defina 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",
],
}
Un archivo TEST_MAPPING contiene una lista de pruebas. Aunque no es un requisito, si crea un archivo TEST_MAPPING, las pruebas que incluya en él se ejecutarán en las pruebas previas al envío y se podrán invocar mediante atest .
Puede consultar la documentación TEST_MAPPING para obtener más información, pero para el ejemplo libfoo_inline_tests , agregue esto al envío previo para permitir las ejecuciones de prueba en TreeHugger:
{
"presubmit": [
{
"name": "libfoo_inline_tests",
},
]
}
Tenga 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 en false , por lo que no es necesario declararlos en archivos TEST_MAPPING .
Para obtener más información sobre cómo funcionan las propiedades auto_gen_config y test_suites , consulte la sección Configuración de la documentación del flujo de trabajo de desarrollo de pruebas .
Propiedades notables de la prueba de óxido
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 definidas en la siguiente tabla se suman a las propiedades comunes importantes que se aplican a todos los módulos. Estos son particularmente importantes para los módulos de prueba de Rust o exhiben un comportamiento único específico del tipo de módulo rust_test .
- test_harness : uso avanzado, el valor predeterminado es verdadero.
Establezca esto en falso si su rust_test implementa su propio arnés de prueba y no necesita usar el arnés de prueba integrado de Rust (en otras palabras, establecer esto en falso no pasará el indicador --test a Rustc).
Evite la duplicación entre Rust_library y Rust_test
Cuando utiliza pruebas de Rust en línea a través de módulos anidados, termina con una duplicación en su archivo Android.bp . El problema es que tienes que 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, puede enumerar las dependencias solo una 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 forma, la biblioteca y el módulo de prueba siempre utilizarán las mismas dependencias.