ماژول های تست

این صفحه اطلاعات اولیه در مورد نحوه ساخت ماژول 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 حاوی لیستی از آزمایشات است. اگرچه الزامی نیست، اما اگر یک فایل TEST_MAPPING ایجاد کنید، آزمایش‌هایی که در آن قرار می‌دهید در آزمایش‌های پیش ارسال اجرا می‌شوند و می‌توان با استفاده از atest فراخوانی کرد.

می‌توانید برای اطلاعات بیشتر به سند TEST_MAPPING مراجعه کنید، اما برای مثال libfoo_inline_tests ، این را برای پیش‌فرستادن اضافه کنید تا آزمایش‌های خود را در 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 : استفاده پیشرفته، پیش فرض درست است.

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

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