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ề thử nghiệm 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 thùng dữ liệu 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 chương trình 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 với ví dụ về libfoo_inline_tests, hãy thêm đoạn mã này vào
presubmit để cho phép chạy chương trình 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 phần gửi trước, trừ phi
unit_tests: được thiết lập thành false nên bạn không cần khai báo những thông tin 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. 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, giá trị 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",
],
}
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 chỉ cần liệt kê các phần phụ thuộc 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.