Trang này cung cấp thông tin cơ bản về cách tạo mô-đun rust_test sử dụng bộ kiểm thử Rust.
Viết chương trình kiểm thử Rust cơ bản
Để xem ví dụ trực tiếp về kiểm thử Rust trên thiết bị và trên máy chủ, hãy xem keystore2 Android.bp hoặc tìm một trong nhiều vùng chứa trong thư mục external/rust/crates.
Mô-đun rust_test tạo bản dựng bằng cờ --test của rustc, tạo các chương trình kiểm thử từ mã được đánh dấu bằng thuộc tính #[test]. Để biết thêm thông tin, hãy xem
Các thuộc tính kiểm thử tham chiếu Rust
.
Xác định mô-đun kiểm thử như sau:
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",
],
}
Tệp TEST_MAPPING chứa danh sách các bài kiểm thử. Mặc dù không bắt buộc,
nếu bạn tạo tệp TEST_MAPPING, các bài kiểm thử bạn đưa vào tệp đó sẽ chạy trong
trước khi gửi thử nghiệm và có thể được gọi bằng atest.
Bạn có thể tham khảo tài liệu về TEST_MAPPING để biết thêm thông tin, nhưng đối với ví dụ libfoo_inline_tests, hãy thêm nội dung này vào để gửi trước nhằm cho phép chạy kiểm thử trên TreeHugger:
{
"presubmit": [
{
"name": "libfoo_inline_tests",
},
]
}
Xin lưu ý rằng các mô-đun rust_test_host chạy theo mặc định trong quá trình gửi trước, trừ phi unit_tests: được đặt thành false. Vì vậy, bạn không cần khai báo các mô-đun này trong tệp TEST_MAPPING.
Để biết thêm thông tin về cách hoạt động của các thuộc tính auto_gen_config và test_suites,
hãy xem phần Cài đặt
của tài liệu Quy trình phát triển kiểm thử.
Các thuộc tính kiểm thử Rust đáng chú ý
Các mô-đun rust_test kế thừa các thuộc tính từ các mô-đun rust_binary như mô tả trên trang Mô-đun nhị phân.
Các thuộc tính được xác định trong bảng bên dưới là ngoài Các thuộc tính chung quan trọng áp dụng cho tất cả các mô-đun. Hai lớp này đặc biệt quan trọng đối với Gỉ
các mô-đun kiểm thử hoặc cho thấy hành vi riêng biệt dành riêng cho loại mô-đun rust_test.
- test_harness: Cách sử dụng nâng cao, mặc định là true.
Đặt giá trị này thành false nếu rust_test của bạn triển khai khai thác kiểm thử riêng, còn bạn không
cần sử dụng phần khai thác kiểm thử Rust tích hợp sẵn (nói cách khác, đặt giá trị này thành false
sẽ không truyền cờ --test đến rustc).
Tránh trùng lặp giữa rust_library và rust_test
Khi sử dụng các chương trình kiểm thử Rust nội tuyến thông qua các mô-đun lồng nhau, bạn sẽ gặp phải tình trạng trùng lặp trong tệp Android.bp. Vấn đề là bạn phải liệt kê các phần phụ thuộc
hai lần, một lần cho rust_library và một lần cho 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",
],
}
Mỗi mô-đun rust_test sẽ liệt kê các phần phụ thuộc giống như
mô-đun rust_library tương ứng. Để đảm bảo tính nhất quán giữa các mô-đun,
bạn có thể liệt kê các phần phụ thuộc chỉ một lần trong mô-đun 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"],
}
Bằng cách này, thư viện và mô-đun kiểm thử sẽ luôn sử dụng cùng một phần phụ thuộc.