Trang này cung cấp thông tin cơ bản về cách xây dựng mô-đun rust_test sử dụng bộ khai thác thử nghiệm Rust.
Viết bài kiểm tra Rust cơ bản
Để biết ví dụ trực tiếp về thử nghiệm 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 thùng trong thư mục external/rust/crates .
Mô-đun rust_test được xây dựng bằng cờ --test của Rustc, tạo ra các thử nghiệm 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 Thuộc tính thử nghiệm tham chiếu Rust .
Xác định một mô-đun thử nghiệm 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 tra. 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 thì các bài kiểm tra bạn đưa vào đó sẽ chạy trong các bài kiểm tra gửi trước và có thể được gọi bằng cách sử dụng atest .
Bạn có thể tham khảo tài liệu TEST_MAPPING để biết thêm thông tin, nhưng đối với ví dụ libfoo_inline_tests , hãy thêm tài liệu này vào phần gửi trước để cho phép chạy thử nghiệm của bạn trên TreeHugger:
{
"presubmit": [
{
"name": "libfoo_inline_tests",
},
]
}
Lưu ý rằng các mô-đun rust_test_host chạy theo mặc định trong presubmit trừ khi unit_tests: được đặt thành false , vì vậy bạn không cần khai báo những mô-đun này trong tệp TEST_MAPPING .
Để biết thêm thông tin về cách hoạt động của 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 thử nghiệm .
Đặc tính thử nghiệm 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ư được 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à phần bổ sung cho các thuộc tính chung quan trọng áp dụng cho tất cả các mô-đun. Đây là những điều đặc biệt quan trọng đối với các mô-đun kiểm tra Rust hoặc thể hiện hành vi độc đáo 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 sai nếu rust_test của bạn triển khai khai thác kiểm tra riêng và bạn không cần sử dụng khai thác kiểm tra Rust tích hợp (nói cách khác, đặt giá trị này thành sai sẽ không chuyển cờ --test sang Rustc).
Tránh trùng lặp giữa Rust_library và Rust_test
Khi bạn sử dụng các thử nghiệm 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 của mình. Vấn đề là bạn phải liệt kê các 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 thử nghiệm sẽ luôn sử dụng các phần phụ thuộc giống nhau.