Módulos de prueba

Esta página proporciona información básica sobre cómo construir un módulo rust_test que use el arnés de prueba de Rust.

Escribiendo 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 de las cajas en el directorio external/rust/crates .

Un módulo rust_test se compila utilizando el indicador --test de --test , que crea pruebas a partir del código marcado con el atributo #[test] . Para obtener más información, consulte la documentación de 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 pruebas previas al envío y se pueden invocar mediante atest .

Puede hacer referencia a la documentación de TEST_MAPPING para obtener más información, pero para el ejemplo de libfoo_inline_tests , agregue esto para enviar previamente para habilitar sus 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 necesita declararlos en los 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 para el tipo de módulo rust_test .

• test_harness : uso avanzado, el valor predeterminado es verdadero.

Establézcalo en falso si su rust_test implementa su propio arnés de prueba y no necesita usar el arnés de prueba Rust incorporado (en otras palabras, establecer esto en falso no pasará el indicador --test a rustc).

Evitar la duplicación entre rust_library y rust_test

Cuando usa 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 listar 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 manera, la biblioteca y el módulo de prueba siempre usarán las mismas dependencias.