Testmodule

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

Einen einfachen Rust-Test schreiben

Ein Live-Beispiel für einen Rust-Test auf dem Gerät und auf dem Host finden Sie unter keystore2 Android.bp oder in einem der vielen Crates im Verzeichnis external/rust/crates.

Ein rust_test-Modul wird mit dem --test-Flag von rustc erstellt. Dadurch werden Tests aus Code erstellt, der mit dem Attribut #[test] gekennzeichnet ist. Weitere Informationen finden Sie in der Dokumentation The Rust Reference Testing Attributes.

Definieren Sie ein Testmodul so:

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. 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 Testläufe auf TreeHugger zu aktivieren:

{
  "presubmit": [
    {
      "name": "libfoo_inline_tests",
    },
  ]
}

rust_test_host-Module werden standardmäßig in Presubmit ausgeführt, sofern unit_tests: nicht auf false festgelegt ist. Sie müssen diese daher nicht in TEST_MAPPING-Dateien deklarieren.

Weitere Informationen zur Funktionsweise der Attribute auto_gen_config und test_suites finden Sie im Abschnitt Einstellungen der Dokumentation zum Workflow für die Testentwicklung.

Wichtige Rust-Testattribute

Die rust_test-Module erben Attribute von rust_binary-Modulen, wie auf der Seite Binärmodule beschrieben.

Die in der Tabelle unten definierten Properties gelten zusätzlich zu den wichtigen gemeinsamen Properties, die für alle Module gelten. Diese sind entweder besonders wichtig für Rust-Testmodule oder weisen ein einzigartiges Verhalten auf, das spezifisch für den Modultyp rust_test ist.

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

Setzen Sie diesen Wert auf „false“, wenn Ihr rust_test ein eigenes Test-Framework implementiert und Sie das integrierte Rust-Test-Framework nicht verwenden müssen. Wenn Sie diesen Wert auf „false“ setzen, wird das Flag --test nicht 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",
    ],
}

In jedem rust_test-Modul werden dieselben Abhängigkeiten wie im entsprechenden rust_library-Modul aufgeführt. Um die Konsistenz zwischen den Modulen zu gewährleisten, 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.