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

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

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

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

إنشاء اختبار مزوَّد بأدوات لتنويعة التصميم

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

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

تتم مشاركة الاختبارات التي تتطلّب أجهزة في مجموعة رموز المصدر src/androidTest/ بين جميع أنواع الإصدارات. عند إنشاء حزمة APK تجريبية للصيغة "MyFlavor" من تطبيقك، يجمع Gradle بين مجموعتَي رموز المصدر src/androidTest/ وsrc/androidTestMyFlavor/.

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

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

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

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

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

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

وكما هو الحال مع مجموعات رموز المصدر الخاصة بتطبيقك، يدمج إصدار Gradle الملفات من مجموعات رموز المصدر المختلفة للاختبار ويتجاهل الملفات المتشابهة. في هذه الحالة، يتجاوز الملف AndroidExampleTest.kt في مجموعة رموز المصدر androidTestMyFlavor الإصدار في مجموعة رموز المصدر 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 مرجع واجهة برمجة التطبيقات.

Kotlin

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

أنيق

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

يمكن لكل صيغة منتج تقوم بضبطها تجاوز الخصائص في الحظر defaultConfig {}. لمزيد من المعلومات، يُرجى الانتقال إلى ضبط إصدارات المنتج.

السمات في المقتطف هي:

الإعداد	الوصف
testApplicationId	تحدّد هذه السمة معرّف التطبيق لحزمة APK التجريبية.
testInstrumentationRunner	تحدِّد هذه السمة اسم الفئة المؤهَّل بالكامل لمشغّل أدوات الاختبار.
testHandleProfiling	إذا تم ضبطها على true، سيتم تفعيل فئة أدوات القياس لبدء عملية إنشاء الملفات الشخصية وإيقافها. إذا تم ضبطها على false، يتم إنشاء الملفات الشخصية طوال فترة تشغيل فئة أدوات القياس.
testFunctionalTest	إذا تم ضبطها على true، يشير ذلك إلى أنّ نظام Android يجب أن يشغّل فئة أدوات القياس كاختبار وظيفي. القيمة التلقائية هي false.

تغيير نوع الإصدار التجريبي

يتم تلقائيًا تنفيذ جميع اختبارات الأجهزة مع نوع الإصدار debug. يمكنك تغيير ذلك إلى نوع التصميم آخر باستخدام السمة testBuildType في ملف build.gradle على مستوى الوحدة. على سبيل المثال، إذا أردت إجراء اختبارات على نوع التصميم staging، عدِّل الملف كما هو موضّح في المقتطف التالي:

Kotlin

android {
    ...
    testBuildType = "staging"
}

أنيق

android {
    ...
    testBuildType "staging"
}

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

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

Kotlin

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

أنيق

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.

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 {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues true

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

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

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

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

تضبط السمة jvmArgs وسيطات آلة جافا الافتراضية(JVM) لآلات جافا الافتراضية(JVM) الخاصة بالاختبار.

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

استخدام وحدات اختبار منفصلة للاختبارات المزوّدة بأدوات

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

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

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

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

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

Kotlin

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

أنيق

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

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