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

يجب أن يحتوي كل نموذج اختبار جديد على ملف إعداد لتوجيه نظام الإنشاء باستخدام البيانات الوصفية للوحدة النمطية والتبعيات في وقت الترجمة وتعليمات التعبئة. يستخدم 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.