Moduli di test

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

Scrivi un test Rust di base

Per un esempio dal vivo di un test Rust sul dispositivo e sull'host, visualizza keystore2 Android.bp o individuane uno tra molti 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 ulteriori informazioni, consultare la documentazione The Rust Reference Testing Attributes .

Definire 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 in esso verranno eseguiti nei test di preinvio e potranno essere richiamati utilizzando atest .

Puoi fare riferimento alla documentazione TEST_MAPPING per ulteriori informazioni, ma per l'esempio libfoo_inline_tests , aggiungi questo al preinvio per abilitare l'esecuzione del 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 su come funzionano le proprietà auto_gen_config e test_suites , vedere la sezione Impostazioni della documentazione del flusso di lavoro di sviluppo test .

Notevoli proprietà del test della ruggine

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

Le proprietà definite nella tabella seguente sono in aggiunta alle importanti proprietà comuni 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.

Impostalo su false se il tuo rust_test implementa il proprio test Harness e non hai bisogno di utilizzare il test Harness integrato in Rust (in altre parole, impostandolo su False non passerà il flag --test a Rust).

Evita la duplicazione tra ruggine_library e ruggine_test

Quando utilizzi i test Rust in linea tramite moduli nidificati, ti ritroverai con la duplicazione nel tuo file Android.bp . Il problema è che devi elencare le dipendenze due volte, una volta per rust_library e una volta 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 corrispondente modulo rust_library . Per garantire la coerenza tra i moduli, puoi elencare le dipendenze solo una 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.