إعداد الاختبار المتقدم

الاختبار في "استوديو Android" اشرح الاختبار من سطر الأوامر كيفية ضبط تهيئة وتشغيل تهيئات الاختبار الأساسية. ومع ذلك، عندما يتم تثبيت التطبيق متطلبات الاختبار أكثر تقدمًا، فقد تحتاج إلى تكييف الاختبار المزيد من التكوينات. على سبيل المثال، قد تحتاج إلى إعداد اختبار متقدم عند عليك إجراء ما يلي:

• إجراء اختبارات قياس حالة التطبيق لخيار إصدار معيّن فقط أو إلغاء ذلك إعدادات البيان.
• تغيير نوع التصميم الذي يتم إجراء الاختبارات عليه أو ضبط Gradle الخيارات.
• استخرِج اختبارات الأدوات من وحدة الاختبار الخاصة بها.
• يمكنك إجراء اختبارات أكثر تقدّمًا كجزء من عملية إعداد ميزة "الدمج المستمر".

توضّح هذه الصفحة طرقًا مختلفة لضبط إعدادات اختباراتك عندما تكون لا تتناسب مع احتياجاتك.

إنشاء اختبار قياسي لصيغة الإصدار

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

لربط الاختبارات المُعدَّة بنُسخة مختلفة من التطبيق، ضَعها في نتائج البحث الخاصة بها. مجموعة المصدر، وتقع في src/androidTestVariantName

يشارك الجميع الاختبارات التي يتم قياسها في مجموعة المصادر src/androidTest/ متغيرات التصميم. عند إنشاء حِزمة APK تجريبية لـ "MyFlapor" صيغة Gradle، وهي تجمع بين src/androidTest/ وsrc/androidTestMyFlavor/ مجموعات المصادر.

لإضافة مجموعة مصادر اختبار لصيغة الإصدار في "استوديو Android"، يُرجى اتّباع الخطوات التالية: الخطوات التالية:

1. في نافذة المشروع، انقر على القائمة واختَر عرض المشروع.
2. ضمن مجلد الوحدة المناسب، انقر بزر الماوس الأيمن على مجلد src انقر على جديد > الدليل.
3. بالنسبة إلى اسم الدليل، أدخِل "androidTestVariantName". على سبيل المثال، إذا لديك نسخة إصدار تسمى "MyFLAor"، استخدام اسم الدليل androidTestMyFlavor
4. انقر على موافق.
5. انقر بزر الماوس الأيمن على الدليل الجديد واختر جديد > الدليل.
6. أدخل "java" كاسم للدليل، ثم انقر على حسنًا.

يمكنك الآن إضافة اختبارات إلى هذا المصدر الجديد من خلال اتّباع خطوات إضافة اختبار جديد. عندما تصل إلى مربع الحوار اختيار دليل الوجهة، حدد الدليل الجديد مجموعة مصدر اختبار الصيغة.

يوضح الجدول التالي مثالاً على كيفية احتمال ظهور ملفات اختبار الأدوات متوفّرة في مجموعات المصادر التي تتوافق مع مجموعات مصادر الرموز البرمجية للتطبيق:

الجدول 1. رمز مصدر التطبيق ومقابله ملفات اختبار قياس حالة التطبيق

المسار إلى فئة التطبيق	مسار فئة اختبار قياس حالة التطبيق
src/main/java/Example.java	src/androidTest/java/AndroidExampleTest.java
src/myFlavor/java/Example.java	src/androidTestMyFlavor/java/AndroidExampleTest.java

وكما هو الحال مع مجموعات مصادر التطبيقات، يتم دمج إصدار Gradle تلغي الملفات من مجموعات مصادر الاختبار المختلفة. في هذه الحالة، عدد الملفات التي تم إلغاؤها في مجموعة المصادر androidTestMyFlavor: AndroidExampleTest.java الإصدار في مجموعة مصادر androidTest. هذا بسبب تكون لمجموعة مصدر نكهة المنتج الأولوية على مجموعة المصدر الرئيسية.

عند اختيار نكهات مختلفة في أداة اختيار صيغ التصميم، يتم عرض مجلدات androidTest المناسبة في طريقة عرض Android إظهار المجلدات المستخدمة:

الشكل 1. تم اختيار متغير واحد (MyFlavor). الـ يتم عرض مجلد "androidTestMyFlavor" في طريقة عرض Android.

لا يظهر المجلد "androidTestMyFlavor" عند عرض خيار آخر. تم تحديد:

الشكل 2. تم اختيار متغير واحد (OtherFlavor). الـ لا يظهر المجلد androidTestMyFlavor في طريقة عرض Android.

يبدو هذا مختلفًا بعض الشيء إذا كنت تستخدم طريقة عرض المشروع، ولكنك المبدأ:

الشكل 3. تم اختيار متغير واحد (MyFlavor). الـ مجلد "androidTestMyFlavor" نشط في عرض المشروع.

عند تحديد خيار مختلف، يبقى المجلد "androidTestMyFlavor" مرئية، ولكن لا تظهر كنشطة:

الشكل 4. تم اختيار متغير واحد (OtherFlavor). الـ مجلد "androidTestMyFlavor" غير نشط في عرض المشروع.

لمزيد من المعلومات عن كيفية دمج مجموعات المصادر، راجِع المقالة مجموعات المصادر:

ضبط إعدادات بيان قياس حالة التطبيق

الاختبارات التي يتم قياسها مُدمَجة في حِزمة APK منفصلة ومزوَّدة بخصائصها الخاصة ملف AndroidManifest.xml. وعندما تنشئ Gradle ملف APK التجريبي، فإنه ملف AndroidManifest.xml تلقائيًا وإعداده مع عقدة <instrumentation>. أحد أسباب تهيئة Gradle لك لهذه العقدة هو التأكد من targetPackage الخاصية اسم حزمة التطبيق الصحيح قيد الاختبار.

لتغيير إعدادات أخرى لهذه العقدة، يمكنك إنشاء إما ملف بيان في مجموعة مصادر الاختبار أو قم بتهيئة مستوى الوحدة ملف واحد (build.gradle)، كما هو موضّح في عينة التعليمة البرمجية التالية. يمكن العثور على القائمة الكاملة بالخيارات في BaseFlavor مرجع واجهة برمجة التطبيقات.

Groovy

android {
    ...
    defaultConfig {
        ...
        testApplicationId "com.example.test"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling true
        testFunctionalTest true
    }
}

Kotlin

android {
    ...
    defaultConfig {
        ...
        testApplicationId = "com.example.test"
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling = true
        testFunctionalTest = true
    }
}

Each product flavor you configure can override properties in the defaultConfig {} block. To learn more, go to Configure product flavors.

The properties in the snippet are:

Setting	Description
testApplicationId	Specifies the application ID for the test APK.
testInstrumentationRunner	Specifies the fully qualified class name of the test instrumentation runner.
testHandleProfiling	If set to true, enables the instrumentation class to start and stop profiling. If set to false, profiling occurs the entire time the instrumentation class is running.
testFunctionalTest	If set to true, indicates that the Android system should run the instrumentation class as a functional test. The default value is false.

Change the test build type

By default, all instrumentation tests run against the debug build type. You can change this to another build type by using the testBuildType property in your module-level build.gradle file. For example, if you want to run your tests against your staging build type, edit the file as shown in the following snippet:

Groovy

android {
    ...
    testBuildType "staging"
}

Kotlin

android {
    ...
    testBuildType = "staging"
}

ضبط خيارات اختبار Gradle

يتيح لك المكوّن الإضافي لنظام Gradle المتوافق مع Android تحديد خيارات معينة لجميع الاختبارات أو لبعضها فقط. في جلسة المعمل، build.gradle على مستوى الوحدة، استخدم testOptions منعها لتحديد الخيارات التي تغيّر طريقة تشغيل Gradle لجميع الاختبارات:

Groovy

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir "$rootDir/test-results"
    }
}

Kotlin

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir = "$rootDir/test-results"
    }
}

تغيّر السمة reportDir الدليل الذي تحفظ فيه Gradle الاختبار. التقارير. تحفظ Gradle تلقائيًا تقارير الاختبار في دليل path_to_your_project/module_name /build/outputs/reports/. يحدد $rootDir المسار نسبيًا إلى الدليل الجذري للمشروع الحالي.

تغيّر السمة resultsDir الدليل الذي تحفظ فيه Gradle الاختبار. نتائجك. تحفظ Gradle نتائج الاختبار تلقائيًا في دليل path_to_your_project/module_name /build/outputs/test-results/. يحدد $rootDir المسار نسبيًا إلى الدليل الجذري للمشروع الحالي.

لتحديد خيارات لاختبارات الوحدة المحلية فقط، اضبط unitTests حظر داخل testOptions

Groovy

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues true

            all {
                jvmArgs '-XX:MaxPermSize=256m'

                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

Kotlin

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues = true

            all {
                jvmArgs = listOf("-XX:MaxPermSize=256m")

                 if (it.name == "testDebugUnitTest") {
                    systemProperty = mapOf("debug" to "true")
                }
                ...
            }
        }
    }
}

بشكلٍ تلقائي، تُستثنى اختبارات الوحدات المحلية من الحالات التي يتم فيها إرسال الرمز تحاول الوصول إلى واجهات برمجة تطبيقات النظام الأساسي لنظام التشغيل Android، ما لم محاكاة لتبعيات Android بنفسك أو باستخدام إطار عمل اختبار مثل النموذج التجريبي مع ذلك، يمكنك تفعيل السمة returnDefaultValues لكي يكون يعرض الاختبار القيمة "صفر" أو "صفر" عند الوصول إلى واجهات برمجة التطبيقات للنظام الأساسي، من طرح استثناء.

تضم كتلة all خيارات للتحكم في كيفية تنفيذ Gradle اختبارات الوحدة المحلية. للحصول على قائمة بجميع الخيارات التي يمكنك تحديدها، اقرأ مستندات Gradle المرجعية

تضبط السمة jvmArgs وسيطات JVM لاختبارات JVM.

يمكنك أيضًا التحقّق من اسم المهمة لتطبيق الخيارات على الاختبارات التي التحديد. في مثال المقتطف، يتم ضبط السمة debug على true، ولكن فقط لمهمة testDebugUnitTest.

استخدام وحدات اختبار منفصلة للاختبارات الموجَّهة

إذا كنت ترغب في الحصول على وحدة مخصصة لاختبارات الأجهزة، لعزل باقي التعليمات البرمجية من اختباراتك، وإنشاء وحدة اختبار منفصلة تكوين بنيته بطريقة مماثلة لتلك الخاصة بوحدة المكتبة.

لإنشاء وحدة اختبار، اتّبِع الخطوات التالية:

1. أنشئ وحدة مكتبة.
2. في ملف build.gradle على مستوى الوحدة، طبِّق com.android.test. المكون الإضافي بدلاً من com.android.library.
3. انقر على مزامنة المشروع .

بعد إنشاء وحدة الاختبار، يمكنك تضمين كود الاختبار في المصدر الرئيسي أو المتغير (على سبيل المثال، src/main/java أو src/variant/java). إذا كانت وحدة التطبيق تحدِّد نكهات منتج متعددة، يمكنك إعادة إنشاء تلك النكهات في وحدة الاختبار الخاصة بك. استخدام التبعية الواعية للمتغير الإدارة أو تحاول وحدة الاختبار اختبار النكهة المطابقة في الوحدة المستهدفة.

تتضمّن وحدات الاختبار صيغة تصحيح أخطاء فقط وتختبرها تلقائيًا. ومع ذلك، يمكنك إنشاء أنواع إنشاءات جديدة لتناسب مشروع التطبيقات الذي تم اختباره. لإجراء وحدة اختبار نوع تصميم مختلف وليس نوع تصحيح الأخطاء، استخدم VariantFilter لإيقاف صيغة تصحيح الأخطاء في المشروع التجريبي، كما هو موضّح:

Groovy

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug')) {
            variant.setIgnore(true);
        }
    }
}

Kotlin

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

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