Testare i moduli

Questa pagina fornisce informazioni di base su come creare un modulo rust_test che utilizza l'infrastruttura di test Rust.

Scrivere un test Rust di base

Per un esempio pratico di test Rust su dispositivo e host, visualizza keystore2 Android.bp o individua uno dei tanti crate nella directory external/rust/crates.

Un modulo rust_test viene creato utilizzando il flag --test di rustc, che crea test dal codice contrassegnato con l'attributo #[test]. Per saperne di più, consulta la documentazione The Rust Reference Testing Attributes.

Definisci un modulo di test nel seguente modo:

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 verranno eseguiti nei test di pre-invio e possono essere richiamati utilizzando atest.

Per ulteriori informazioni, puoi consultare la documentazione TEST_MAPPING, ma per l'esempio libfoo_inline_tests, aggiungi questo codice 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 saperne di più sul funzionamento delle proprietà auto_gen_config e test_suites, consulta la sezione Impostazioni della documentazione Flusso di lavoro di sviluppo dei test.

Proprietà di test Rust degne di nota

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 mostrano 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 il tuo rust_test implementa il proprio banco di prova e non devi utilizzare il banco di prova Rust integrato (in altre parole, impostando questo valore su false non verrà passato il flag --test a rustc).

Evitare la duplicazione tra rust_library e rust_test

Quando utilizzi test Rust incorporati tramite moduli nidificati, si verifica una duplicazione 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.