تكوين البناء البسيط

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

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

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

مثال

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

يتم تضمين لقطة هنا للراحة:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["android-support-test"],
    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: ["android-support-test"],

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

في هذا المثال ، الأشياء التي قد تكون مفيدة بشكل عام للاختبارات:

android-support-test هو مُعد مسبقًا لمكتبة دعم اختبار Android ، والتي تتضمن عداء الاختبار الجديد AndroidJUnitRunner : بديل عن InstrumentationTestRunner المدمج الذي تم إيقافه الآن ، مع دعم إطار اختبار JUnit4. اقرأ المزيد في Test apps on Android .

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

    certificate: "platform",

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

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

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

    test_suites: ["device-tests"],

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

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

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

تحصل الإعدادات الاختيارية التالية على شرح:

    test_config: "path/to/hello_world_test.xml"

يوجه إعداد test_config نظام البناء الذي يحتاج هدف الاختبار الخاص بك إلى تكوين محدد. بشكل افتراضي ، يتم ربط ملف AndroidTest.xml الموجود بجوار Android.bp config.

    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 إلى تكوين الاختبار الذي تم إنشاؤه تلقائيًا. عندما يقوم الاتحاد التجاري بتشغيل التكوين التجريبي ، سيتم تخطي الاختبار إذا كانت خاصية الجهاز لـ ro.product.first_api_level < test_min_api_level .