Testmodule

Auf dieser Seite finden Sie grundlegende Informationen zum Erstellen eines rust_test-Moduls, das den Rust-Test-Harness verwendet.

Einen einfachen Rust-Test 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 unter die Attribute für Rust Reference Testing Dokumentation.

Definieren Sie ein Testmodul:

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 Dokumentation zu TEST_MAPPING. weitere Informationen. Fügen Sie für das libfoo_inline_tests-Beispiel dies Vorab einreichen, um Ihre Testläufe auf TreeHugger zu aktivieren:

{
  "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, du musst sie also nicht deklarieren in TEST_MAPPING Dateien.

Weitere Informationen zur Funktionsweise der Properties auto_gen_config und test_suites finden Sie im Abschnitt Einstellungen der Dokumentation zum Testentwicklungs-Workflow.

Wichtige Rust-Testeigenschaften

Die rust_test-Module übernehmen Eigenschaften von rust_binary-Modulen, wie auf der Seite Binary Modules beschrieben.

Die in der folgenden Tabelle definierten Properties ergänzen die wichtigen allgemeinen Properties, 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 rust_test-Modultyp spezifisch ist.

  • test_harness: Erweiterte Verwendung, standardmäßig auf „true“ gesetzt.

Setzen Sie diesen Wert auf „false“, wenn Ihr rust_test einen eigenen Test-Harnisch implementiert und Sie muss das integrierte Rost-Test-Harnisch verwendet werden (d. h., es wird auf „false“ gesetzt) nicht das Flag --test an rustc übergeben).

Duplikate zwischen „rust_library“ und „rust_test“ vermeiden

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 listet am Ende dieselben Abhängigkeiten auf wie das Modul entsprechendes 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"],
}

Auf diese Weise verwenden die Bibliothek und das Testmodul immer dieselben Abhängigkeiten.