Módulos de teste

Esta página fornece informações básicas sobre como construir um módulo rust_test que usa o equipamento de teste Rust.

Escreva um teste básico de ferrugem

Para obter um exemplo ao vivo de um teste de ferrugem no dispositivo e no host, consulte keystore2 Android.bp ou localize uma em muitas das caixas no diretório external/rust/crates .

Um módulo rust_test é construído usando o sinalizador --test do Rustc, que cria testes a partir do código marcado com o atributo #[test] . Para obter mais informações, consulte a documentação dos atributos de teste de referência do Rust .

Defina um módulo de teste da seguinte forma:

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, os testes incluídos nele serão executados em testes de pré-envio e poderão ser invocados usando atest .

Você pode consultar a documentação TEST_MAPPING para obter mais informações, mas para o exemplo libfoo_inline_tests , adicione isto ao pré-envio para permitir a execução de testes no TreeHugger:

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

Observe que os módulos rust_test_host são executados por padrão no pré-envio, a menos que unit_tests: esteja definido como false , portanto, você não precisa declará-los nos arquivos TEST_MAPPING .

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

Propriedades notáveis ​​de teste de ferrugem

Os módulos rust_test herdam propriedades dos módulos rust_binary conforme descrito na página Módulos Binários .

As propriedades definidas na tabela abaixo são adicionais às propriedades comuns importantes que se aplicam a todos os módulos. Eles são particularmente importantes para módulos de teste Rust ou exibem um comportamento exclusivo específico para o tipo de módulo rust_test .

• test_harness : uso avançado, o padrão é verdadeiro.

Defina isso como false se seu rust_test implementar seu próprio equipamento de teste e você não precisar usar o equipamento de teste Rust integrado (em outras palavras, definir isso como false não passará o sinalizador --test para Rustc).

Evite duplicação entre ferrugem_library e ferrugem_test

Ao usar testes Rust inline por meio de módulos aninhados, você acaba duplicando seu arquivo Android.bp . O problema é que você precisa listar as dependências duas vezes, uma vez 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 acabará listando as mesmas dependências do módulo rust_library correspondente. Para garantir a consistência entre os módulos, você pode listar as dependências apenas uma vez em um 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"],
}

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