Moduli di test

Questa pagina fornisce informazioni di base su come creare un modulo rust_test che utilizza il test harness Rust.

Scrivere un test Rust di base

Per un esempio pratico di un test Rust on-device e on-host, visualizza keystore2 Android.bp, o individuane uno in molte delle casse nella directory external/rust/crates.

Un modulo rust_test viene compilato utilizzando il flag --test di rustc, che crea test del codice contrassegnato dall'attributo #[test]. Per saperne di più, consulta la documentazione relativa agli attributi di test di riferimento di Rust.

Definisci un modulo di test come segue:

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 file TEST_MAPPING contiene un elenco di test. Sebbene non sia un requisito, se crei un file TEST_MAPPING, i test che includi al suo interno verranno eseguiti in test pre-invio e possono essere richiamati utilizzando atest.

Per ulteriori informazioni, puoi fare riferimento alla documentazione di TEST_MAPPING, ma per l'esempio libfoo_inline_tests, aggiungi quanto segue a presubmit per attivare le esecuzioni di test su TreeHugger:

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

Tieni presente che i moduli rust_test_host vengono eseguiti per impostazione predefinita in presubmit, a meno che unit_tests: non sia impostato su false, quindi non è necessario dichiararli nei file TEST_MAPPING.

Per ulteriori informazioni sul funzionamento delle proprietà auto_gen_config e test_suites, consulta la sezione Impostazioni della documentazione Flusso di lavoro per lo sviluppo di test.

Proprietà di test Rust importanti

I moduli rust_test ereditano le proprietà dai moduli rust_binary come descritto nella pagina Moduli binari.

Le proprietà definite nella tabella seguente si aggiungono alle proprietà comuni importanti che si applicano a tutti i moduli. Questi sono particolarmente importanti per i moduli di test Rust o presentano un comportamento unico specifico per il tipo di modulo rust_test.

• test_harness: utilizzo avanzato, il valore predefinito è true.

Imposta questo valore su false se rust_test implementa il proprio test di test e non è necessario utilizzare il sistema di test antiruggine integrato (in altre parole, l'impostazione su false non trasmetterà il flag --test a rustc).

Evita la duplicazione tra rust_library e rust_test

Quando utilizzi i test Rust in linea tramite moduli nidificati, si verificano duplicazioni nel file Android.bp. Il problema è che devi elencare le dipendenze due volte, una per rust_library e una per 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",
    ],
}

Ogni modulo rust_test finirà per elencare le stesse dipendenze del modulo rust_library corrispondente. Per garantire la coerenza tra i moduli, puoi elencare le dipendenze una sola volta in un modulo 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"],
}

In questo modo, la libreria e il modulo di test utilizzeranno sempre le stesse dipendenze.