Тестовые модули

На этой странице представлена ​​основная информация о том, как создать модуль rust_test , использующий тестовую программу Rust.

Напишите базовый тест Rust

Для живого примера теста Rust на устройстве и на хосте просмотрите keystore2 Android.bp или найдите один из множества ящиков в каталоге external/rust/crates .

Модуль rust_test собирается с использованием флага Rusc --test , который создает тесты из кода, отмеченного атрибутом #[test] . Дополнительную информацию см. в документации Атрибуты эталонного тестирования Rust .

Определите тестовый модуль следующим образом:

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

Файл TEST_MAPPING содержит список тестов. Хотя это и не является обязательным требованием, если вы создадите файл TEST_MAPPING, включенные в него тесты будут выполняться в тестах предварительной отправки и могут быть вызваны с помощью atest .

Вы можете обратиться к документации TEST_MAPPING для получения дополнительной информации, но для примера libfoo_inline_tests добавьте это в предварительную отправку, чтобы разрешить запуск тестов на TreeHugger:

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

Обратите внимание, что модули rust_test_host запускаются по умолчанию при предварительной отправке, если для unit_tests: не установлено значение false , поэтому вам не нужно объявлять их в файлах TEST_MAPPING .

Дополнительные сведения о том, как работают свойства auto_gen_config и test_suites , см. в разделе «Настройки» документации по рабочему процессу разработки тестов .

Примечательные свойства теста на ржавчину

Модули rust_test наследуют свойства модулей rust_binary , как описано на странице Двоичные модули .

Свойства, определенные в таблице ниже, дополняют важные общие свойства , применимые ко всем модулям. Они либо особенно важны для тестовых модулей Rust, либо демонстрируют уникальное поведение, специфичное для типа rust_test .

• test_harness : Расширенное использование, по умолчанию — true.

Установите для этого параметра значение false, если ваш rust_test реализует свой собственный тестовый пакет и вам не нужно использовать встроенный тестовый пакет Rust (другими словами, установка этого параметра в значение false не приведет к передаче флага --test в Rustc).

Избегайте дублирования Rust_library и Rust_test.

Когда вы используете встроенные тесты Rust через вложенные модули, вы получаете дублирование в файле Android.bp . Проблема в том, что вам придется перечислять зависимости дважды: один раз для rust_library и один раз для 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",
    ],
}

Каждый модуль rust_test будет содержать те же зависимости, что и соответствующий модуль rust_library . Чтобы обеспечить согласованность между модулями, вы можете перечислить зависимости только один раз в 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"],
}

Таким образом, библиотека и тестовый модуль всегда будут использовать одни и те же зависимости.