Mô-đun kiểm thử

Trang này cung cấp thông tin cơ bản về cách tạo một mô-đun rust_test sử dụng bộ kiểm thử Rust.

Viết một bài 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ủ lưu trữ, hãy xem keystore2 Android.bp hoặc tìm một ví dụ trong nhiều crate trong thư mục external/rust/crates.

Một mô-đun rust_test được tạo bằng cờ --test của rustc, tạo các 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 Các thuộc tính kiểm thử tham chiếu Rust.

Xác định một 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 kiểm thử. Mặc dù không bắt buộc, nhưng nếu bạn tạo tệp TEST_MAPPING, các kiểm thử mà bạn đưa vào tệp đó sẽ chạy trong các kiểm thử trước khi gửi 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 nội dung này vào giai đoạn trước khi gửi để 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 giai đoạn kiểm tra trước khi gửi 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ử đáng chú ý của Rust

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.

Ngoài các thuộc tính được xác định trong bảng bên dưới, còn có 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 mô-đun đặc biệt quan trọng đối với các mô-đun kiểm thử Rust hoặc có 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 triển khai bộ kiểm thử riêng và bạn không cần sử dụng bộ kiểm thử Rust tích hợp (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 bài 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 chỉ có thể 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.