Moduły testowe

Na tej stronie znajdziesz podstawowe informacje o tworzeniu modułu rust_test, który korzysta z testów Rust.

Pisanie podstawowego testu Rust

Aby zobaczyć przykład testu Rust na urządzeniu i na hoście, otwórz plik keystore2 Android.bp lub znajdź jeden z wielu plików w katalogu external/rust/crates.

Kompilacja modułu rust_test jest wykonywana za pomocą flagi rustc --test, która tworzy testy z kodu oznaczonego atrybutem #[test]. Więcej informacji znajdziesz w dokumentacji The Rust Reference Testing Attributes (w języku angielskim).

Zdefiniuj moduł testowy w ten sposób:

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",
    ],
}

Plik TEST_MAPPING zawiera listę testów. Chociaż nie jest to wymagane, jeśli utworzysz plik TEST_MAPPING, testy, które w nim uwzględnisz, będą uruchamiane w ramach testów przed przesłaniem i można je wywołać za pomocą atest.

Więcej informacji znajdziesz w dokumentacji TEST_MAPPING, ale w przypadku przykładu libfoo_inline_tests dodaj do przed przesłaniem ten kod, aby umożliwić testowanie w TreeHugger:

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

Pamiętaj, że moduły rust_test_host są domyślnie uruchamiane przed przesłaniem, chyba że parametr unit_tests: ma wartość false, więc nie musisz ich deklarować w plikach TEST_MAPPING.

Więcej informacji o tym, jak działają właściwości auto_gen_config i test_suites, znajdziesz w sekcji Ustawienia w dokumentacji Test Development Workflow (ang. „Test Development Workflow”).

Właściwości testowe Rust

Moduły rust_test dziedziczą właściwości z modułów rust_binary zgodnie z opisem na stronie Moduły binarne.

Właściwości zdefiniowane w tabeli poniżej są uzupełnieniem ważnych wspólnych właściwości, które dotyczą wszystkich modułów. Są one szczególnie ważne w przypadku modułów testowych Rust lub mają unikalne zachowanie specyficzne dla typu modułu rust_test.

• test_harness: użycie zaawansowane, domyślnie wartość to „true” (prawda).

Ustaw tę opcję na false, jeśli rust_test implementuje własny zestaw testów i nie musisz używać wbudowanego zestawu testów Rust (czyli ustawienie tej opcji na false nie przekaże flagi --test do rustc).

Unikaj powielania między rust_library i rust_test

Jeśli używasz wbudowanych testów Rust za pomocą zagnieżdżonych modułów, w pliku Android.bp dochodzi do duplikacji. Problem polega na tym, że musisz podać listę zależności rust_library i 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",
    ],
}

Każdy moduł rust_test będzie zawierał te same zależności co odpowiadający mu moduł rust_library. Aby zapewnić spójność między modułami, możesz wymienić zależności tylko raz w module rust_defaults:

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"],
}

Dzięki temu biblioteka i moduł testu będą zawsze używać tych samych zależności.