自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
測試模組
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本頁面提供如何建構使用 Rust 測試套件的 rust_test
模組的基本資訊。
編寫基本的 Rust 測試
如需裝置端和主機端 Rust 測試的實際範例,請查看 keystore2 Android.bp,或在 external/rust/crates
目錄中的眾多 Crate 中找出一個。
rust_test
模組會使用 rustc 的 --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",
},
]
}
請注意,除非 unit_tests:
設為 false
,否則 rust_test_host
模組預設會在提交前執行,因此您不需要在 TEST_MAPPING
檔案中宣告這些模組。
如要進一步瞭解 auto_gen_config
和 test_suites
屬性的運作方式,請參閱 測試開發工作流程說明文件中的「設定」一節。
值得注意的 Rust 測試屬性
rust_test
模組會繼承 rust_binary
模組的屬性,如「二進位模組」頁面所述。
除了適用於所有模組的重要通用屬性,下表中定義的屬性也是如此。這些方法對 Rust 測試模組特別重要,或會顯示 rust_test
模組類型專屬的獨特行為。
- test_harness:進階用途,預設值為 true。
如果 rust_test
實作自己的測試輔助工具,且您不需要使用內建的 Rust 測試輔助工具,請將此值設為 false (也就是將此值設為 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"],
}
這樣一來,程式庫和測試模組就會一律使用相同的依附元件。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],null,["# Test modules\n\nThis page provides basic information on how to build a `rust_test` module\nthat uses the Rust test harness.\n\nWrite a basic Rust test\n-----------------------\n\nFor a live example of an on-device and on-host Rust test, view\n[keystore2 Android.bp](https://android.googlesource.com/platform/system/security/+/2f503e597130e1d65dbf9fb4cd0fbd6a2f9ccb07/keystore2/Android.bp),\nor locate one in many of the crates in the `external/rust/crates` directory.\n\nA `rust_test` module builds using rustc's `--test` flag, which creates tests\nout of code marked with the `#[test]` attribute. For more information, see\nthe [The Rust Reference Testing Attributes](https://doc.rust-lang.org/reference/attributes/testing.html)\ndocumentation.\n\nDefine a test module as follows: \n\n rust_test {\n name: \"libfoo_inline_tests\",\n\n // Specify the entry point of your library or binary to run all tests\n // specified in-line with the test attribute.\n srcs: [\"src/lib.rs\"],\n\n // Tradefed test suite to include this test in.\n test_suites: [\"general-tests\"],\n\n // Autogenerate the test config\n auto_gen_config: true,\n\n rustlibs: [\n \"libfoo\",\n ],\n }\n\nA `TEST_MAPPING` file contains a list of tests. Although it's not a requirement,\nif you do create a TEST_MAPPING file, the tests you include in it will run in\npresubmit tests, and can be invoked using [`atest`](/docs/core/tests/development/atest).\n\nYou can reference the [TEST_MAPPING documentation](/compatibility/tests/development/test-mapping)\nfor more information, but for the `libfoo_inline_tests` example, add this to\npresubmit to enable your test runs on TreeHugger: \n\n {\n \"presubmit\": [\n {\n \"name\": \"libfoo_inline_tests\",\n },\n ]\n }\n\nNote that `rust_test_host` modules run by default in presubmit unless\n`unit_tests:` is set to `false`, so you don't need to declare these\nin `TEST_MAPPING` files.\n\nFor more information on how the `auto_gen_config` and `test_suites` properties work,\nsee the [Settings](/docs/core/tests/development/blueprints#settings) section\nof the [Test Development Workflow](/docs/core/tests/development) documentation.\n\nNotable Rust test properties\n----------------------------\n\nThe `rust_test` modules inherit properties from `rust_binary` modules as described on\nthe [Binary Modules](/docs/setup/build/rust/building-rust-modules/binary-modules)\npage.\n\nThe properties defined in the table below are in addition to the\n[Important common properties](/docs/setup/build/rust/building-rust-modules/android-rust-modules#important-common-properties)\nthat apply to all modules. These are either particularly important to Rust\ntest modules, or exhibit unique behavior specific to the `rust_test` module type.\n\n- **test_harness**: Advanced usage, defaults to true.\n\nSet this to false if your `rust_test` implements its own test harness and you don't\nneed to use the built-in Rust test harness (in other words, setting this to false\n*won't* pass the `--test` flag to rustc).\n\nAvoid duplication between rust_library and rust_test\n----------------------------------------------------\n\nWhen you use inline Rust tests via nested modules, you end up with duplication\nin your `Android.bp` file. The problem is that you have to list the dependencies\ntwice, once for `rust_library` and once for `rust_test`: \n\n rust_library {\n name: \"libfoo\",\n srcs: [\"src/lib.rs\"],\n rustlibs: [\n \"libx\",\n \"liby\",\n \"libz\",\n ],\n }\n\n rust_test {\n name: \"libfoo_inline_tests\",\n srcs: [\"src/lib.rs\"],\n test_suites: [\"general-tests\"],\n rustlibs: [\n \"libx\",\n \"liby\",\n \"libz\",\n ],\n }\n\nEach `rust_test` module will end up listing the same dependencies as the\ncorresponding `rust_library` module. To ensure consistency between the modules,\nyou can list the dependencies just once in a `rust_defaults` module: \n\n rust_defaults {\n name: \"libfoo_defaults\",\n srcs: [\"src/lib.rs\"],\n rustlibs: [\n \"libx\",\n \"liby\",\n \"libz\",\n ],\n }\n\n rust_library {\n name: \"libfoo\",\n defaults: [\"libfoo_defaults\"],\n }\n\n rust_test {\n name: \"libfoo_inline_tests\",\n defaults: [\"libfoo_defaults\"],\n test_suites: [\"general-tests\"],\n }\n\nThis way, the library and the test module will always use the same dependencies."]]