إعدادات تصميم بسيطة

يجب أن يحتوي كل نموذج اختبار جديد على ملف إعداد لتوجيه نظام الإنشاء باستخدام البيانات الوصفية للوحدة النمطية والتبعيات في وقت الترجمة وتعليمات التعبئة. يستخدم Android الآن نظام التصميم Soong لتسهيل عملية ضبط الاختبار.

يستخدم Soong ملفات Blueprint أو .bp، وهي عبارة عن أوصاف بسيطة تصريحية تشبه JSON للوحدات التي سيتم إنشاؤها. يحل هذا التنسيق محل نظام Make المستخدَم في الإصدارات السابقة. يمكنك الاطّلاع على ملفات مرجع Soong في لوحة بيانات التكامل المستمر للحصول على التفاصيل الكاملة.

لاستيعاب الاختبارات المخصّصة أو استخدام مجموعة أدوات اختبار التوافق (CTS) لنظام التشغيل Android، اتّبِع الخطوات الواردة في إعداد الاختبار المعقّد بدلاً من ذلك.

مثال

تأتي الإدخالات أدناه من ملف إعدادات Blueprint النموذجي هذا: /platform_testing/tests/example/instrumentation/Android.bp

في ما يلي لقطة شاشة لتسهيل الأمر:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["androidx.test.runner"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

يُرجى العِلم أنّ تصنيف android_test في البداية يشير إلى أنّ هذا اختبار. في المقابل، يشير تضمين android_app إلى أنّ هذا الملف هو حزمة إنشاء.

الإعدادات

في ما يلي شرح للإعدادات التالية:

    name: "HelloWorldTests",

يجب ضبط الإعداد name عند تحديد نوع الوحدة android_test (في بداية الفقرة). يمنح هذا الإعداد اسمًا للوحدة، وسيتم تسمية حزمة APK الناتجة بالاسم نفسه مع إضافة اللاحقة .apk، مثلاً، في هذه الحالة، سيتم تسمية حزمة APK الاختبارية الناتجة بالاسم HelloWorldTests.apk. بالإضافة إلى ذلك، يحدّد هذا الملف أيضًا اسم هدف الإنشاء الخاص بالوحدة، حتى تتمكّن من استخدام make [options] <HelloWorldTests> لإنشاء وحدة الاختبار وجميع العناصر التابعة لها.

    static_libs: ["androidx.test.runner"],

يوجّه الإعداد static_libs نظام التصميم إلى دمج محتويات الوحدات المسماة في حزمة APK الناتجة للوحدة الحالية. يعني هذا أنّه من المتوقّع أن ينتج كل وحدة مسماة ملف .jar، وسيتم استخدام محتواه لتحديد مراجع مسار الفئة أثناء وقت التجميع، بالإضافة إلى دمجه في حزمة APK الناتجة.

وحدة androidx.test.runner هي وحدة مسبقة الإنشاء لمكتبة AndroidX Test Runner، وتتضمّن أداة تشغيل الاختبار AndroidJUnitRunner. يتوافق AndroidJUnitRunner مع إطار عمل الاختبار JUnit4، وقد حلّ محل InstrumentationTestRunner في نظام التشغيل Android 10. يمكنك الاطّلاع على مزيد من المعلومات حول اختبار تطبيقات Android في مقالة اختبار تطبيقات Android.

إذا كنت بصدد إنشاء وحدة جديدة لأدوات القياس، عليك دائمًا البدء باستخدام مكتبة androidx.test.runner كأداة تنفيذ الاختبار. تتضمّن شجرة المصدر للنظام الأساسي أيضًا أُطر اختبار مفيدة أخرى، مثل ub-uiautomator وmockito-target وeasymock وغيرها.

    certificate: "platform",

يوجّه الإعداد certificate نظام الإنشاء إلى توقيع حزمة APK باستخدام الشهادة نفسها المستخدَمة في النظام الأساسي. ويكون ذلك ضروريًا إذا كان الاختبار يستخدم إذنًا أو واجهة برمجة تطبيقات محمية بالتوقيع. يُرجى العِلم أنّ هذا الإعداد مناسب للاختبار المستمر للمنصة، ولكن لا يجب استخدامه في وحدات اختبار CTS. يُرجى العِلم أنّ هذا المثال يستخدم إعداد الشهادة هذا لغرض التوضيح فقط، إذ لا يحتاج رمز الاختبار في المثال إلى توقيع حزمة APK الاختبارية باستخدام شهادة النظام الأساسي الخاصة.

إذا كنت تكتب أداة قياس لأحد مكوناتك التي تقع خارج خادم النظام، أي أنّها مجمّعة بشكل أو بآخر مثل حزمة APK لتطبيق عادي، باستثناء أنّها مضمّنة في صورة النظام وقد تكون تطبيقًا ذا امتيازات، فمن المحتمل أنّ أداة القياس ستستهدف حزمة التطبيق (راجِع القسم أدناه حول ملف البيان) الخاص بمكونك. في هذه الحالة، قد يحتوي ملف makefile الخاص بالتطبيق على إعداد certificate خاص به، ويجب أن يحتفظ نموذج أدوات القياس بالإعداد نفسه. ويرجع ذلك إلى أنّه لاستهداف أدواتك في التطبيق قيد الاختبار، يجب توقيع حزمة APK للاختبار وحزمة APK للتطبيق باستخدام الشهادة نفسها.

في حالات أخرى، لن تحتاج إلى هذا الإعداد على الإطلاق، إذ سيوقّع نظام التصميم على التطبيق باستخدام شهادة تلقائية مضمّنة استنادًا إلى صيغة الإصدار، ويُطلق عليها عادةً اسم dev-keys.

    test_suites: ["device-tests"],

يجعل الإعداد test_suites من السهل العثور على الاختبار من خلال أداة اختبار Trade Federation. يمكن إضافة مجموعات أخرى هنا، مثل CTS، حتى يمكن مشاركة هذا الاختبار.

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

الإعدادات الاختيارية

في ما يلي شرح للإعدادات الاختيارية:

    test_config: "path/to/hello_world_test.xml"

يُعلِم الإعداد test_config نظام التصميم أنّ هدف الاختبار يحتاج إلى إعدادات محدّدة. بشكل تلقائي، يتم ربط AndroidTest.xml بجانب Android.bp بعملية الضبط.

    auto_gen_config: true

يشير الإعداد auto_gen_config إلى ما إذا كان سيتم إنشاء إعدادات الاختبار تلقائيًا أم لا. إذا لم تكن السمة AndroidTest.xml متوفّرة بجانب Android.bp، ليس عليك ضبط هذه السمة على "صحيح" بشكل صريح.

    require_root: true

يوجّه الإعداد require_root نظام التصميم إلى إضافة RootTargetPreparer إلى إعدادات الاختبار التي يتم إنشاؤها تلقائيًا. يضمن ذلك تشغيل الاختبار بأذونات الجذر.

    test_min_api_level: 29

يطلب الإعداد test_min_api_level من نظام التصميم إضافة MinApiLevelModuleController إلى إعدادات الاختبار التي يتم إنشاؤها تلقائيًا. عندما تنفّذ Trade Federation إعدادات الاختبار، سيتم تخطّي الاختبار إذا كانت قيمة السمة ro.product.first_api_level في الجهاز أقل من test_min_api_level.