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 mã kiểm thử Rust cơ bản
Để xem ví dụ trực tiếp về chương trình kiểm thử Rust trên thiết bị và trên máy chủ lưu trữ, hãy xem keystore2 Android.bp hoặc tìm một trong nhiều ngăn 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 tài liệu về 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ù đây không phải là yêu cầu bắt buộc, nhưng nếu bạn tạo tệp TEST_MAPPING, các thử nghiệm bạn đưa vào tệp đó sẽ chạy trong các thử nghiệm gửi lại 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 trong 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ừ 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. Các mô-đun này đặc biệt quan trọng đối với mô-đun kiểm thử Rust hoặc thể hiện 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 và bạn không cần
sử dụng khai thác kiểm thử Rust tích hợp sẵn (nói cách khác, việ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",
],
}
Cuối cùng, 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.