الاختبار في استوديو Android والاختبار من سطر الأوامر يشرحان كيفية إعداد وتشغيل إعدادات الاختبار الأساسية ومع ذلك، عندما يصبح تطبيقك ومتطلبات الاختبار أكثر تقدمًا، قد تحتاج إلى تكييف إعدادات الاختبار بشكل أكبر. على سبيل المثال، قد تحتاج إلى إعداد اختباري متقدم عندما تريد إجراء ما يلي:
- إجراء الاختبارات المؤدّية إلى إصدار معيّن فقط من إصدار معيّن أو إلغاء إعدادات البيان
- يمكنك تغيير نوع الإصدار الذي تُجري الاختبارات عليه أو ضبط خيارات Gradle الخاصة به.
- استخرِج الاختبارات المُعدّة إلى وحدة الاختبار الخاصة بها.
- يمكنك إجراء اختبار أكثر تقدّمًا كجزء من عملية إعداد ميزة "الدمج المستمر".
توضّح هذه الصفحة طرقًا مختلفة لإعداد اختباراتك عندما لا تتناسب الإعدادات التلقائية مع احتياجاتك.
إنشاء اختبار مبرمج لصيغة إصدار
إذا كان مشروعك يتضمّن إنشاء صيغ باستخدام مجموعات مصادر فريدة، يمكنك تضمين الاختبارات المعدّة التي تتوافق مع مجموعات المصادر هذه. يحافظ هذا على تنظيم رمز الاختبار الخاص بك ويتيح لك إجراء الاختبارات التي تنطبق فقط على متغير إصدار معين.
لربط الاختبارات المُعدّة بنُسخة من الإصدار، يمكنك وضعها في مجموعة مصادر خاصة بها، وهي على الرابط
src/androidTestVariantName
.
وتشارك جميع متغيرات الإصدار
الاختبارات الآلية في مجموعة المصدر src/androidTest/
. عند إنشاء حزمة APK تجريبية لنسخة "MyFlavor" في تطبيقك، تجمع Gradle بين مجموعتي المصادر src/androidTest/
وsrc/androidTestMyFlavor/
.
لإضافة مصدر اختبار لنسخة الإصدار في "استوديو Android"، اتّبِع الخطوات التالية:
- في نافذة المشروع، انقر على القائمة واختَر طريقة عرض المشروع.
- ضمن مجلد الوحدة المناسب، انقر بزر الماوس الأيمن على مجلد src وانقر على جديد > الدليل.
- بالنسبة إلى اسم الدليل، أدخِل "androidTestVariantName". على سبيل المثال، إذا كان لديك
صيغة إصدار تسمى MyFlavor، استخدِم اسم الدليل
androidTestMyFlavor
. - انقر على حسنًا.
- انقر بزر الماوس الأيمن على الدليل الجديد واختر جديد > الدليل.
- أدخِل "JavaScript" كاسم الدليل، ثم انقر على OK (حسنًا).
يمكنك الآن إضافة اختبارات إلى مجموعة المصدر الجديدة هذه من خلال اتّباع خطوات إضافة اختبار جديد. عند وصولك إلى مربع الحوار اختيار دليل الوجهة، حدِّد مجموعة مصادر اختبار المتغيّر الجديد.
يعرض الجدول التالي مثالاً على كيفية بقاء ملفات اختبار الأدوات في مجموعات المصدر التي تتوافق مع مجموعات مصدر الرمز للتطبيق:
المسار إلى فئة التطبيق | مسار لفئة اختبار قياس حالة التطبيق |
---|---|
src/main/java/Example.java
|
src/androidTest/java/AndroidExampleTest.java
|
src/myFlavor/java/Example.java
|
src/androidTestMyFlavor/java/AndroidExampleTest.java
|
تمامًا كما يحدث مع مجموعات مصادر التطبيقات، يتم دمج ملفات Gradle
وإلغاء الملفات الواردة من مجموعات مصادر الاختبار المختلفة. في هذه الحالة، سيؤدي الملف
AndroidExampleTest.java
في مجموعة المصدر androidTestMyFlavor
إلى إلغاء
النسخة في مجموعة المصدر androidTest
. ذلك لأن مجموعة مصدر نكهة المنتج لها الأولوية على مجموعة المصدر الرئيسية.
عند اختيار نكهات مختلفة في أداة اختيار خيارات الإصدار، يتم عرض مجلدات androidTest
المناسبة في طريقة العرض Android لعرض المجلدات المستخدَمة:
لا يتم عرض المجلد androidTestMyFlavor
عند تحديد خيار مختلف:
يبدو هذا مختلفًا قليلاً إذا كنت تستخدم عرض المشروع، ولكن ينطبق المبدأ نفسه:
عند تحديد خيار مختلف، سيظل مجلد androidTestMyFlavor
مرئيًا، ولكن لن يظهر على أنه نشط:
لمزيد من المعلومات عن كيفية دمج مجموعات المصدر، راجع مجموعات المصادر.
ضبط إعدادات بيان الأدوات
تكون الاختبارات المُعدّة مدمَجة في حزمة APK منفصلة تتضمّن ملف AndroidManifest.xml
خاص بها. عندما تنشئ أداة Gradle حزمة APK تجريبية، فإنها تنشئ ملف AndroidManifest.xml
تلقائيًا وتضبطه باستخدام العقدة <instrumentation>
.
أحد الأسباب التي تؤدي إلى إعداد Gradle لهذه العقدة لك هو التأكّد من أن
السمة targetPackage
تحدّد اسم الحزمة الصحيح للتطبيق الذي يخضع للاختبار.
لتغيير إعدادات أخرى لهذه العقدة، يمكنك إنشاء ملف بيان آخر في مجموعة مصادر الاختبار أو ضبط ملف build.gradle
على مستوى الوحدة، كما هو موضّح في نموذج الرمز التالي. ويمكن العثور على القائمة الكاملة للخيارات في مرجع واجهة برمجة التطبيقات
BaseFlavor
.
رائع
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 لجميع اختباراتك:
رائع
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
.
رائع
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 بنفسك أو باستخدام إطار عمل اختبار مثل Mockito. مع ذلك، يمكنك تفعيل السمة returnDefaultValues
بحيث يعرض الاختبار إما قيمة فارغة أو صفرًا عند الوصول إلى واجهات برمجة التطبيقات للنظام الأساسي، بدلاً من طرح استثناء.
تضم مجموعة all
خيارات للتحكم في كيفية تنفيذ Gradle لاختبارات الوحدات المحلية. للحصول على قائمة بجميع الخيارات التي يمكنك تحديدها، اقرأ
مستندات Gradle المرجعية.
تضبط السمة jvmArgs
وسيطات JVM لنظام تشغيل JVM تجريبيًا.
يمكنك أيضًا التحقق من اسم المهمة لتطبيق الخيارات على الاختبارات التي
تحددها فقط. في مثال المقتطف، يتم ضبط السمة debug
على true
، وذلك على المهمة testDebugUnitTest
فقط.
استخدام وحدات اختبار منفصلة للاختبارات المعدّة
إذا أردت الحصول على وحدة مخصصة للاختبارات المعدّة، لعزل باقي التعليمات البرمجية من اختباراتك، يمكنك إنشاء وحدة اختبار منفصلة وتهيئة إصدارها على نحو مشابه لوحدة مكتبة ما.
لإنشاء وحدة اختبار، اتّبِع الخطوات التالية:
- أنشئ وحدة مكتبة.
- في ملف
build.gradle
على مستوى الوحدة، طبِّق المكوِّن الإضافيcom.android.test
بدلاً منcom.android.library
. - انقر على مزامنة المشروع .
بعد إنشاء وحدة الاختبار، يمكنك تضمين رمز الاختبار في مجموعة المصدر الرئيسية أو مجموعة الصيغ (على سبيل المثال، src/main/java
أو src/variant/java
). إذا كانت وحدة التطبيق تحدد نكهات منتجات متعددة، يمكنك إعادة إنشاء تلك النكهات في وحدة الاختبار.
باستخدام إدارة التبعية الواعية بالسياق،
تحاول وحدة الاختبار اختبار النكهة المتطابقة في الوحدة المستهدفة.
تحتوي الوحدات التجريبية على خيار تصحيح الأخطاء فقط وتختبره. ومع ذلك، يمكنك إنشاء أنواع إصدار جديدة لمطابقة مشروع التطبيق الذي تم اختباره. لجعل
وحدة الاختبار نوع إصدار مختلفًا وليس نوع تصحيح الأخطاء، استخدِم
VariantFilter
لإيقاف صيغة تصحيح الأخطاء في مشروع الاختبار، كما هو موضّح:
رائع
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Kotlin
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
إذا كنت تريد أن تستهدِف وحدة اختبارية نكهات معيّنة فقط أو تنشئ أنواعًا معيّنة من
التطبيق، يمكنك استخدام السمة matchingFallbacks
لاستهداف الصيغ التي تريد اختبارها فقط. هذا أيضًا يمنع وحدة الاختبار من الاضطرار
إلى تهيئة هذه المتغيرات لنفسها.