Moduły testowe

Ta strona zawiera podstawowe informacje na temat budowania modułu rust_test wykorzystującego wiązkę testową Rust.

Napisz podstawowy test na rdzę

Aby zobaczyć przykładowy test Rusta na urządzeniu i na hoście, wyświetl plik keystore2 Android.bp lub zlokalizuj jedną z wielu skrzynek w katalogu external/rust/crates .

Moduł rust_test jest tworzony przy użyciu flagi rustc --test , która tworzy testy z kodu oznaczonego atrybutem #[test] . Aby uzyskać więcej informacji, zobacz dokumentację atrybutów testowania referencyjnego rdzy .

Zdefiniuj moduł testowy w następujący 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, zawarte w nim testy zostaną uruchomione w testach przed przesłaniem i można je wywołać za pomocą atest .

Możesz odwołać się do dokumentacji TEST_MAPPING, aby uzyskać więcej informacji, ale w przypadku przykładu libfoo_inline_tests dodaj to do wstępnego przesłania, aby umożliwić uruchamianie testów na TreeHugger:

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

Zauważ, że moduły rust_test_host działają domyślnie w presubmit, chyba że unit_tests: jest ustawione na false , więc nie musisz deklarować ich w plikach TEST_MAPPING .

Aby uzyskać więcej informacji na temat działania właściwości auto_gen_config i test_suites , zobacz sekcję Ustawienia w dokumentacji przepływu pracy tworzenia testów .

Godne uwagi właściwości testu rdzy

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

Właściwości zdefiniowane w poniższej tabeli stanowią dodatek do ważnych wspólnych właściwości , które mają zastosowanie do wszystkich modułów. Są one albo szczególnie ważne dla modułów testowych Rust, albo wykazują unikalne zachowanie specyficzne dla typu modułu rust_test .

• test_harness : Zaawansowane użycie, domyślnie true.

Ustaw tę opcję na false, jeśli Twój rust_test implementuje własną wiązkę testową i nie musisz używać wbudowanej wiązki testowej Rust (innymi słowy, ustawienie tej opcji na false nie spowoduje przekazania flagi --test do rustc).

Unikaj powielania plików rust_library i rust_test

Kiedy używasz wbudowanych testów Rust poprzez zagnieżdżone moduły, kończy się to duplikacją w pliku Android.bp . Problem polega na tym, że musisz dwukrotnie wyświetlić listę zależności, raz dla rust_library i raz dla 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 wyświetli te same zależności, co odpowiedni moduł rust_library . Aby zapewnić spójność między modułami, możesz wyświetlić listę 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"],
}

W ten sposób biblioteka i moduł testowy będą zawsze korzystać z tych samych zależności.