На этой странице представлена основная информация о том, как создать модуль 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"],
}
Таким образом, библиотека и тестовый модуль всегда будут использовать одни и те же зависимости.
, На этой странице представлена основная информация о том, как создать модуль 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"],
}
Таким образом, библиотека и тестовый модуль всегда будут использовать одни и те же зависимости.