ماژول های تست

این صفحه اطلاعات اولیه‌ای در مورد نحوه ساخت یک ماژول rust_test که از ابزار تست Rust استفاده می‌کند، ارائه می‌دهد.

یک تست Rust پایه بنویسید

برای مشاهده‌ی یک مثال زنده از تست Rust روی دستگاه و روی میزبان، به keystore2 Android.bp مراجعه کنید، یا یکی از آن‌ها را در بسیاری از جعبه‌های موجود در دایرکتوری external/rust/crates پیدا کنید.

یک ماژول rust_test با استفاده از پرچم --test در rustc ساخته می‌شود، که تست‌هایی را از کدی که با ویژگی #[test] مشخص شده است، ایجاد می‌کند. برای اطلاعات بیشتر، به مستندات The Rust Reference Testing Attributes مراجعه کنید.

یک ماژول تست را به صورت زیر تعریف کنید:

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",
    ],
}

یک فایل TEST_MAPPING شامل لیستی از تست‌ها است. اگرچه ایجاد این فایل الزامی نیست، اما اگر آن را ایجاد کنید، تست‌هایی که در آن قرار می‌دهید، در تست‌های پیش از ارسال اجرا می‌شوند و می‌توانند با استفاده از atest فراخوانی شوند.

برای اطلاعات بیشتر می‌توانید به مستندات TEST_MAPPING مراجعه کنید، اما برای مثال libfoo_inline_tests ، این را به presubmit اضافه کنید تا اجرای تست شما روی TreeHugger فعال شود:

{
  "presubmit": [
    {
      "name": "libfoo_inline_tests",
    },
  ]
}

توجه داشته باشید که ماژول‌های rust_test_host به طور پیش‌فرض در presubmit اجرا می‌شوند، مگر اینکه unit_tests: روی false تنظیم شده باشد، بنابراین نیازی به اعلام این موارد در فایل‌های TEST_MAPPING نیست.

برای اطلاعات بیشتر در مورد نحوه عملکرد ویژگی‌های auto_gen_config و test_suites ، به بخش تنظیمات مستندات گردش کار توسعه تست مراجعه کنید.

خواص قابل توجه تست زنگ زدگی

ماژول‌های rust_test ویژگی‌هایی را از ماژول‌های rust_binary به ارث می‌برند، همانطور که در صفحه ماژول‌های دودویی توضیح داده شده است.

ویژگی‌های تعریف‌شده در جدول زیر علاوه بر ویژگی‌های مشترک مهمی هستند که برای همه ماژول‌ها اعمال می‌شوند. این ویژگی‌ها یا به‌طور ویژه برای ماژول‌های تست Rust مهم هستند، یا رفتار منحصربه‌فردی را مختص به نوع ماژول rust_test نشان می‌دهند.

• test_harness : کاربرد پیشرفته، مقدار پیش‌فرض true است.

اگر rust_test شما مهار تست مخصوص به خود را پیاده‌سازی می‌کند و نیازی به استفاده از مهار تست داخلی Rust ندارید، این را روی false تنظیم کنید (به عبارت دیگر، تنظیم این مقدار روی false، پرچم --test را به rustc منتقل نمی‌کند ).

از تکرار بین rust_library و rust_test جلوگیری کنید

وقتی از تست‌های درون‌خطی Rust از طریق ماژول‌های تودرتو استفاده می‌کنید، در نهایت با تکرار در فایل Android.bp خود مواجه می‌شوید. مشکل این است که باید وابستگی‌ها را دو بار فهرست کنید، یک بار برای rust_library و یک بار برای 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",
    ],
}

هر ماژول rust_test در نهایت همان وابستگی‌های ماژول rust_library مربوطه را فهرست می‌کند. برای اطمینان از سازگاری بین ماژول‌ها، می‌توانید وابستگی‌ها را فقط یک بار در ماژول 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"],
}

به این ترتیب، کتابخانه و ماژول تست همیشه از وابستگی‌های یکسانی استفاده می‌کنند.