Módulos de teste

Nesta página, você encontrará informações básicas sobre como criar um módulo rust_test que usa o arcabouço de testes do Rust.

Como programar um teste básico do Rust

Para ver um exemplo em tempo real de um teste do Rust no dispositivo e no host, consulte o keystore2 Android.bp ou localize um nas várias caixas do diretório external/rust/crates.

Um módulo rust_test é criado usando a sinalização --test do rustc, que cria testes com código marcado com o atributo #[test]. Para mais informações, consulte a documentação Atributos de teste de referência do Rust (em inglês).

Defina um módulo de teste desta maneira:

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",
    ],
}

Um arquivo TEST_MAPPING contém uma lista de testes. Embora não seja um requisito, se você criar um arquivo TEST_MAPPING, ele será executado em testes de pré-envio e poderá ser invocado usando atest.

É possível consultar a documentação do TEST_MAPPING para mais informações, mas, para o exemplo libfoo_inline_tests, adicione esse atributo no pré-envio para ativar as execuções de teste no TreeHugger:

{
  "presubmit": [
    {
      "name": "libfoo_inline_tests",
    },
  ]
}

Os módulos rust_test_host são executados por padrão no pré-envio, a menos que os unit_tests: sejam definidos como false. Portanto, não é necessário os declarar em arquivos TEST_MAPPING.

Para mais informações sobre como as propriedades auto_gen_config e test_suites funcionam, consulte a seção Configurações da documentação de Fluxo de trabalho do desenvolvimento de testes.

Propriedades importantes de teste do Rust

Os módulos rust_test herdam propriedades de módulos rust_binary, conforme descrito na página Módulos binários.

As propriedades definidas na tabela abaixo funcionam em conjunto com as Propriedades comuns importantes que se aplicam a todos os módulos. Elas são particularmente importantes para módulos de teste do Rust ou apresentam um comportamento único específico para o tipo de módulo rust_test.

• test_harness: uso avançado, o padrão é definido como "true" (verdadeiro).

Defina como falso se o rust_test implementar o próprio arcabouço de testes e você não precisar usar o integrado do Rust. Em outras palavras, a definição como falso não vai transmitir a sinalização --test para o rustc.

Como evitar a duplicação entre rust_library e rust_test

Ao usar testes Rust in-line com módulos aninhados, você acaba tendo a duplicação no seu arquivo Android.bp. O problema é que é necessário listar as dependências duas vezes, uma para rust_library e outra 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 acaba listando as mesmas dependências que o rust_library correspondente. Para garantir a consistência entre os módulos, é possível listar as dependências apenas uma vez em um 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"],
}

Dessa forma, a biblioteca e o módulo de teste sempre vão usar as mesmas dependências.