Diese Seite bietet grundlegende Informationen zum Erstellen eines rust_test Moduls, das das Rust-Testgeschirr verwendet.
Schreiben Sie einen einfachen Rust-Test
Für ein Live-Beispiel eines Rust-Tests auf dem Gerät und auf dem Host sehen Sie sich keystore2 Android.bp an oder suchen Sie eines in vielen der Kisten im Verzeichnis external/rust/crates .
Ein rust_test Modul wird mit dem Flag --test von rustc erstellt, das Tests aus Code erstellt, der mit dem Attribut #[test] markiert ist. Weitere Informationen finden Sie in der Dokumentation The Rust Reference Testing Attributes .
Definieren Sie ein Testmodul wie folgt:
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",
],
}
Eine TEST_MAPPING Datei enthält eine Liste von Tests. Obwohl dies keine Voraussetzung ist, werden die darin enthaltenen Tests, wenn Sie eine TEST_MAPPING-Datei erstellen, in Presubmit-Tests ausgeführt und können mit atest aufgerufen werden.
Weitere Informationen finden Sie in der TEST_MAPPING-Dokumentation . Für das Beispiel libfoo_inline_tests fügen Sie dies jedoch zu Presubmit hinzu, um Ihre Testläufe auf TreeHugger zu ermöglichen:
{
"presubmit": [
{
"name": "libfoo_inline_tests",
},
]
}
Beachten Sie, dass rust_test_host Module standardmäßig in presubmit ausgeführt werden, es sei denn, unit_tests: ist auf false gesetzt, sodass Sie diese nicht in TEST_MAPPING Dateien deklarieren müssen.
Weitere Informationen zur Funktionsweise der Eigenschaften auto_gen_config und test_suites finden Sie im Abschnitt „Einstellungen“ der Dokumentation zum Testentwicklungsworkflow .
Bemerkenswerte Rosttesteigenschaften
Die rust_test Module erben Eigenschaften von rust_binary Modulen, wie auf der Seite „Binärmodule“ beschrieben.
Die in der folgenden Tabelle definierten Eigenschaften gelten zusätzlich zu den wichtigen gemeinsamen Eigenschaften , die für alle Module gelten. Diese sind entweder besonders wichtig für Rust-Testmodule oder weisen ein einzigartiges Verhalten auf, das für den Modultyp rust_test spezifisch ist.
- test_harness : Erweiterte Verwendung, Standardwert ist „true“.
Setzen Sie dies auf „false“, wenn Ihr rust_test seinen eigenen Test-Harness implementiert und Sie den integrierten Rust-Test-Harness nicht verwenden müssen (mit anderen Worten: Wenn Sie dies auf „false“ setzen, wird das Flag --test nicht an rustc übergeben).
Vermeiden Sie Duplikate zwischen rust_library und rust_test
Wenn Sie Inline-Rust-Tests über verschachtelte Module verwenden, kommt es zu Duplikaten in Ihrer Android.bp Datei. Das Problem besteht darin, dass Sie die Abhängigkeiten zweimal auflisten müssen, einmal für rust_library und einmal für 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",
],
}
Jedes rust_test Modul listet am Ende dieselben Abhängigkeiten auf wie das entsprechende rust_library Modul. Um die Konsistenz zwischen den Modulen sicherzustellen, können Sie die Abhängigkeiten nur einmal in einem rust_defaults Modul auflisten:
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"],
}
Auf diese Weise verwenden die Bibliothek und das Testmodul immer dieselben Abhängigkeiten.