Auf dieser Seite finden Sie grundlegende Informationen zum Erstellen eines rust_test-Moduls, das den Rust-Test-Harness verwendet.
Einfachen Rusttest schreiben
Ein Live-Beispiel für einen On-Device- und On-Host-Rust-Test finden Sie unter keystore2 Android.bp oder in vielen der Crates im Verzeichnis external/rust/crates.
Ein rust_test-Modul wird mit dem Flag --test von rustc erstellt, wodurch Tests aus Code erstellt werden, der mit dem Attribut #[test] gekennzeichnet ist. Weitere Informationen finden Sie in der Dokumentation zu 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. Es ist zwar keine Voraussetzung, aber wenn Sie eine TEST_MAPPING-Datei erstellen, werden die darin enthaltenen Tests in Presubmit-Tests ausgeführt und können mit atest aufgerufen werden.
Weitere Informationen finden Sie in der TEST_MAPPING-Dokumentation. Fügen Sie für das libfoo_inline_tests-Beispiel Folgendes zu „presubmit“ hinzu, um Ihre Tests auf TreeHugger auszuführen:
{
"presubmit": [
{
"name": "libfoo_inline_tests",
},
]
}
Beachten Sie, dass rust_test_host-Module standardmäßig beim Vorabsenden ausgeführt werden, es sei denn, unit_tests: ist auf false gesetzt. Sie müssen sie also nicht in TEST_MAPPING-Dateien deklarieren.
Weitere Informationen zur Funktionsweise der Attribute auto_gen_config und test_suites finden Sie in der Dokumentation zum Workflow zur Testentwicklung im Abschnitt Einstellungen.
Wichtige Rust-Testeigenschaften
Die rust_test-Module erben Eigenschaften von rust_binary-Modulen, wie auf der Seite Binary Modules beschrieben.
Die in der folgenden Tabelle definierten Attribute gelten zusätzlich zu den wichtigen allgemeinen Attributen, die für alle Module gelten. Diese sind entweder besonders wichtig für Rust-Testmodule oder zeigen ein spezielles Verhalten für den Modultyp rust_test.
- test_harness: Erweiterte Verwendung, standardmäßig auf „true“ gesetzt.
Legen Sie diesen Wert auf „false“ fest, wenn Ihre rust_test einen eigenen Test-Harness implementiert und Sie den integrierten Rust-Test-Harness nicht verwenden müssen. Wenn Sie diesen Wert auf „false“ festlegen, 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 ist, 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 enthält dann dieselben Abhängigkeiten wie das entsprechende rust_library-Modul. Um für Konsistenz zwischen den Modulen zu sorgen, 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"],
}
So verwenden die Bibliothek und das Testmodul immer dieselben Abhängigkeiten.