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.

Escrevendo um teste básico de Rust

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

Um módulo rust_test é construído usando o sinalizador --test do --test , que cria testes fora do código marcado com o atributo #[test] . Para obter mais informações, consulte a documentação The Rust Reference Testing Attributes .

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 para pré-enviar para habilitar suas execuções de teste no TreeHugger:

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

Observe que os módulos rust_test_host são executados por padrão em presubmit, 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 teste .

Propriedades notáveis ​​do 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 os 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 é true.

Defina isso como false se o 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).

Evitando a duplicação entre rust_library e rust_test

Quando você usa testes de Rust embutidos por meio de módulos aninhados, você acaba com duplicação em seu arquivo Android.bp . O problema é que você tem que 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 acabará listando as mesmas dependências que o 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 sempre usarão as mesmas dependências.