Module testen

Diese Seite enthält grundlegende Informationen zum Erstellen eines rust_test-Moduls das das Rost-Test-Harnisch verwendet.

Einfachen Rusttest schreiben

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

Ein rust_test-Modul wird mit dem --test-Flag von rustc erstellt, das Tests erstellt aus dem Code, 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. Das ist zwar keine Voraussetzung, Wenn Sie eine TEST_MAPPING-Datei erstellen, werden die darin enthaltenen Tests in Presubmit-Tests erstellt und kann 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 Attribute auto_gen_config und test_suites finden Sie im Bereich Einstellungen. in der Dokumentation zum Workflow zur Testentwicklung.

Wichtige Eigenschaften von Rosttests

Die rust_test-Module erben die Eigenschaften von rust_binary-Modulen, wie unter die Binärmodule Seite.

Die in der folgenden Tabelle definierten Eigenschaften gelten zusätzlich zu den Wichtige allgemeine Attribute die für alle Module gelten. Sie sind für Rust entweder besonders wichtig, Testmodule enthalten oder ein spezielles Verhalten für den Modultyp rust_test zeigen.

• 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 das integrierte Rost-Test-Harnisch verwenden (d. h., es wird auf „false“ gesetzt) nicht das Flag --test an rustc übergeben).

Duplikate zwischen „rust_library“ und „rust_test“ vermeiden

Wenn Sie Rust-Inline-Tests über verschachtelte Module verwenden, kommt es am Ende zu Duplizierung in der Datei Android.bp. Das Problem ist, dass Sie die Abhängigkeiten zweimal, 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 Einheitlichkeit 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"],
}

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