Módulos de prueba

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.